Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

On Sat, Jul 6, 2024 at 5:12 AM Bernd Böckmann via Freedos-devel
 wrote:
>
> Like Jerome I also would prefer to put the repository under the
> Gitlab FreeDOS group[1] or alternatively under the fdos[2] group at
> Github. Gitlab would be the more logical choice, I think. But Github
> would have the benefit that there are still more people with an account
> for it.

Well, it won't be under "FDOS" because that's not "The FreeDOS
Project." FDOS is Jeremy's project, I think. (I don't think I knew
Jeremy was using the FreeDOS fish on the "FDOS" GitHub - he probably
should use something else or it will confuse people to think that's an
official FreeDOS GitHub.)

I like the idea of putting the docs under the FreeDOS GitLab group at
. That's where we host a live copy of the
source code, so it makes sense to put the documentation there too. The
process is the same to download a zip archive of everything in a
repository/folder. For example, anyone can download the code to Choice
with this:
https://gitlab.com/FreeDOS/base/choice/-/archive/master/choice-master.zip

..so it's easy enough to automate grabbing a snapshot of the Markdown
docs as a zip file (GitLab also supports tar.gz, tar.bz2, and tar).

> I like Wolfs idea of automatically generating a "documentation site"
> from the Git repository. He mentioned hugo[3] as a static site
> generator. This seems to be a good fit. mdbook[4] would be a more
> documentation focussed software, but is not nearly as flexible as hugo.

It's actually pretty easy to create a "documentation site" without
using a static site generator like Hugo. Once you have the Markdown
files, it's just a matter of putting everything into a place that a
display system can find it. That's pretty easy for me to set up.

> From the beginning, we should put an emphasis on also generating proper
> (with a table of contents etc.) PDFs from the documentation.

I think we can do that automatically using pandoc, which we'd need to
do anyway to turn Markdown into HTML.

> Like already mentioned, having the documentation in markdown format
> would give us the opportunity to automate many things, like building an
> offline documentation from it. As Jim noted, we should establish some
> form of code style considering the constrains given by the different
> output formats and target system we would like to support. A few things
> / questions come into my mind:
>
> - Restrict to UTF-8 encoding to make conversion to different DOS
> codepages for translated documentation straightforward
>
> - Verbatim text like code snippets should be restricted to 78 characters
> a line, so that it fits without a line break on a DOS screen, or
> alternatively create a viewer for it that supports horizontal scrolling
> on the verbatim text while reflowing the "ordinary" text paragraphs.
>
> ? Technically, while I doubt anyone is using it at all, there is a 40
> column text mode. While probably not worth dealing with this it would
> not be a bad thing to design everything that this could be supported
> at some time.
>
> ? Maybe using things like tables should be considered a "do not",
> because it is questionable if these look good on a 80 (or even 40)
> column display when converted to a different format for offline viewing
> under DOS. It could be made to work if the tables get converted to
> verbatim text blocks and the horizontal scrolling thing gets implemented
> in a DOS viewer.
>
> ? We should think about how to generate some form of index for the
> documentation. This would be especially important for the DOS viewers.

+1 Yes to all of that! I think creating the "front page" index will
probably take a little coding so it's automated, but not hard.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jerome Shidel via Freedos-devel]

Hi,

> On Jul 6, 2024, at 6:12 AM, Bernd Böckmann via Freedos-devel 
>  wrote:
> 
> Like Jerome I also would prefer to put the repository under the Gitlab 
> FreeDOS group[1] or alternatively under the fdos[2] group at Github. Gitlab 
> would be the more logical choice, I think. But Github would have the benefit 
> that there are still more people with an account for it.

There is a 4th option. Since it is all text, it could live over at the FreeDOS 
Translation Project (aka FD-NLS)[5] on Github. But, I think the Gitlab FreeDOS 
group[1] is a better place. 

Actually, I think it would be better for the work at FD-NLS and FDOS to be 
maintained in the GitLab group. In part to consolidate things, but mainly, I 
think the permissions system on Gitlab is more flexible and better suited for 
large projects whose contributors come and go. 

However, both FD-NLS and FDOS existed before the Gitlab FreeDOS group. It is 
asking a lot of any contributor to those projects to move to a new location. 
Maybe someday they could be brought under the same umbrella. But for now, it is 
easier to just keep them where they are. 

> 
> I like Wolfs idea of automatically generating a "documentation site" from the 
> Git repository. He mentioned hugo[3] as a static site generator. This seems 
> to be a good fit. mdbook[4] would be a more documentation focussed software, 
> but is not nearly as flexible as hugo.

Another nice feature of both is their Gitlab and Github Pages[6][7]. 

Used in combination with YAML and the CI/CD of those platforms, it could 
automatically create a themed browsable website of the documentation.

As an example, over at FD-NLS[5], I have a script (that I run locally) which 
compares basic kitten style NLS translation files and checks for things like 
missing keys. The output of that script is also pushed to the remote project on 
GitHub. When that report changes, the CI/CD will update the GitHub pages to 
display the “pretty” html version[8] of the report regarding translation 
status. 

> 
> From the beginning, we should put an emphasis on also generating proper (with 
> a table of contents etc.) PDFs from the documentation.
> 
> Like already mentioned, having the documentation in markdown format would 
> give us the opportunity to automate many things, like building an offline 
> documentation from it. As Jim noted, we should establish some form of code 
> style considering the constrains given by the different output formats and 
> target system we would like to support. A few things / questions come into my 
> mind:
> 
> - Restrict to UTF-8 encoding to make conversion to different DOS codepages 
> for translated documentation straightforward
> 
> - Verbatim text like code snippets should be restricted to 78 characters a 
> line, so that it fits without a line break on a DOS screen, or alternatively 
> create a viewer for it that supports horizontal scrolling on the verbatim 
> text while reflowing the "ordinary" text paragraphs.
> 
> ? Technically, while I doubt anyone is using it at all, there is a 40 column 
> text mode. While probably not worth dealing with this it would not be a bad 
> thing to design everything that this could be supported at some time.
> 
> ? Maybe using things like tables should be considered a "do not", because it 
> is questionable if these look good on a 80 (or even 40) column display when 
> converted to a different format for offline viewing under DOS. It could be 
> made to work if the tables get converted to verbatim text blocks and the 
> horizontal scrolling thing gets implemented in a DOS viewer.

I think all the constraints could be enforced at commit/merge. A while back 
AndyStamp provided some “workflows” to the FD-NLS project that did some of what 
you suggest. Things like verifying the UTF-8 and codepage conversion files. 
Something similar could be done on either Git. 

> 
> ? We should think about how to generate some form of index for the 
> documentation. This would be especially important for the DOS viewers.
> 
> 
> [1] https://gitlab.com/FreeDOS
> [2] https://github.com/FDOS
> [3] https://gohugo.io/
> [4] https://github.com/rust-lang/mdBook
> 
> Greetings, Bernd
> 

[5] https://github.com/shidel/fd-nls 
[6] https://docs.gitlab.com/ee/user/project/pages/ 

[7] https://pages.github.com 
[8] https://shidel.github.io/fd-nls/report.html 


:-)

Jerome


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Bernd Böckmann via Freedos-devel]

Like Jerome I also would prefer to put the repository under the Gitlab FreeDOS 
group[1] or alternatively under the fdos[2] group at Github. Gitlab would be 
the more logical choice, I think. But Github would have the benefit that there 
are still more people with an account for it.

I like Wolfs idea of automatically generating a "documentation site" from the 
Git repository. He mentioned hugo[3] as a static site generator. This seems to 
be a good fit. mdbook[4] would be a more documentation focussed software, but 
is not nearly as flexible as hugo.

>From the beginning, we should put an emphasis on also generating proper (with 
>a table of contents etc.) PDFs from the documentation.

Like already mentioned, having the documentation in markdown format would give 
us the opportunity to automate many things, like building an offline 
documentation from it. As Jim noted, we should establish some form of code 
style considering the constrains given by the different output formats and 
target system we would like to support. A few things / questions come into my 
mind:

- Restrict to UTF-8 encoding to make conversion to different DOS codepages for 
translated documentation straightforward

- Verbatim text like code snippets should be restricted to 78 characters a 
line, so that it fits without a line break on a DOS screen, or alternatively 
create a viewer for it that supports horizontal scrolling on the verbatim text 
while reflowing the "ordinary" text paragraphs.

? Technically, while I doubt anyone is using it at all, there is a 40 column 
text mode. While probably not worth dealing with this it would not be a bad 
thing to design everything that this could be supported at some time.

? Maybe using things like tables should be considered a "do not", because it is 
questionable if these look good on a 80 (or even 40) column display when 
converted to a different format for offline viewing under DOS. It could be made 
to work if the tables get converted to verbatim text blocks and the horizontal 
scrolling thing gets implemented in a DOS viewer.

? We should think about how to generate some form of index for the 
documentation. This would be especially important for the DOS viewers.


[1] https://gitlab.com/FreeDOS
[2] https://github.com/FDOS
[3] https://gohugo.io/
[4] https://github.com/rust-lang/mdBook

Greetings, Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Richard Stoltenberg via Freedos-devel]

Ideas Maybe using:
1.  open library.
2.  include portable documentation with betas of freedos
3.  wiki info can sometimes be exported to pdf, maybe someone has?
4.  privately elect a friend to copy your data to.
5.  use a video recorder or obs studio...



On Thu, Jul 4, 2024 at 11:23 PM Jim Hall via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hi everyone. I am following up on my email from a week ago, about the wiki.
>
> To summarize: I discovered that our wiki had been spammed, but
> fortunately I found it only a day after it was spammed.
>
> I discovered the spamming on June 27, and immediately shut down the
> wiki and emailed the freedos-user email list about it:
>
> On Thu, Jun 27, 2024 at 10:37 AM Jim Hall  wrote:
> >
> > I just realized that someone started spamming our wiki yesterday. So
> > I've taken that down until I can clean it out and apply a patch.
> >
> > Great. Just when a bunch of people would be likely to visit the wiki
> > to learn more about us.
>
> Unfortunately, the only backup was right before I started copying over
> most of the content, and they spammed the site before the next backup
> - and I had already made a ton of updates to the wiki in the weeks
> leading up to the 30th anniversary on June 29. So rolling back to a
> previous backup basically wipes out the wiki.
>
> I can't attach screenshots on the email list, so I've created a
> temporary page at https://wiki.freedos.org/spammed/ that has
> screenshots and a version of this email.
>
> Whoever spammed the wiki, I don't think they mangled any existing wiki
> pages, probably to stay under the radar. That means our content is
> still there, so we can copy/paste it out of the wiki.
>
> I found out about the spammed wiki because I was searching for the
> answer to a question someone asked me about the history of FreeDOS,
> and I thought we had a "history" page. I deleted these first 3 pages
> before I realized the extent of the spamming.
>
> But they created hundreds and hundreds of new pages, most (all?) of
> them not linked to from any other pages on the wiki (orphaned). They
> also created many hundreds of dummy users.
>
> The web page I linked to has a screenshot from the Orphaned pages
> report, showing 500 pages at a time, sorted alphabetically, and over
> half of page 1 is "pages that start with a number." Page 1 ends with
> "BBB," page 2 goes to "Fiber," and page 3 goes to "Ideal." So you can
> see that this is a really long list of pages.
>
> Doing a spot check on these pages and looking at the creation date for
> each, I'm pretty sure the hack happened a day or two before I found it
> on June 27.
>
>
> So, where do we go from here?
>
> I could rebuild the wiki. However, that would require basically
> rebuilding from scratch.
>
> Maintaining a Mediawiki requires a lot of work. You basically have to
> jump onto a new version as soon as they release a new one, because
> they often fix security issues (probably like the one that caused our
> problem). We were on the 1.41.x version, and the Mediawiki website*
> says "The 1.42.0 stable release came out on 27 June 2024." That was
> shortly after our wiki was spammed. I'm not excited about a future
> where I need to drop all my other work immediately, just to apply a
> new Mediawiki version to the wiki website.
> *see https://www.mediawiki.org/wiki/MediaWiki_1.42
>
> Even before this issue, I was thinking about how to integrate some of
> our "non-wiki" content into the wiki website. For example, we have
> some ebooks at https://www.freedos.org/books/ and content from the
> press kit that I wanted to migrate into the wiki in some way - but
> these aren't really "wiki" topics, they are longer form. And I wanted
> to copy the articles I've written about FreeDOS into the wiki - but
> again, these don't fit as "wiki" topics.
>
> Years ago, we created a "FreeDOS Documentation Project" website that
> hosted all of our "how-to" articles, "technotes," and other long form
> topics. We retired that when SourceForge set up a shared wiki for all
> projects hosted at SourceForge, and we thought it would be easier to
> maintain a wiki. And for a time, that worked well, until most folks
> stopped contributing to the wiki. We had a few who updated the wiki,
> but like two or three people, including me. And of course: later,
> SourceForge stopped managing a shared wiki, and that's when we set up
> our own wiki (which lived on freedos.sourceforge.net for a long time
> before SF did an update that broke the wiki and I had to move the wiki
> to the new server).
>
> Looking at how pe

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Eric Auer via Freedos-devel]

Hi Jim, I asked around a bit and got some recommendations:

https://en.wikipedia.org/wiki/Wikipedia:Vandalism#Tools

https://en.wikipedia.org/wiki/Wikipedia:Cleaning_up_vandalism/Tools

In other wiki engines, you could for example filter for
changes by NEWCOMERS (people who have fewer than 4 days
of activity or 10 edits) so you could just rollback all
changes from those botarmy accounts via mass moderation.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Wolf Bergenheim via Freedos-devel]

Hi,

On Fri, Jul 5, 2024 at 8:07 PM Jim Hall via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> I really like your suggestion of using GitHub and Markdown to make it
> easier to write the docs, share the docs, and include the docs in the
> FreeDOS distribution! That's more extensible than my suggestion of
> having an online web-only place to host 'how-to' guides. Let me add to
> your idea with another idea:
>
>
I like the way this is going, but thought I'd add to that with what I'm
doing with DOG and the documentation.

I use a static website generator, hugo, which basically adds styling to
the markdown I write for the docs.
The generator takes the markdown and applies a theme and spits
out HTML. You can see the source for it here:
https://gitlab.com/sirwolf77/dogweb

For something bigger with multiple contributors you could set it up
on a website to regularly do a git pull to pull fresh content to the site.
Authors would only need to commit to the git repository and then the
automation would pull it to the site.


> What if we use plain GitHub and Markdown to collect FreeDOS
> documentation. I have the 'freedosproject' username there
> <https://github.com/freedosproject/> but mostly so no one else would
> grab the username. I've been using it to share some of the demo
> programs I've written for the YouTube channel. Let's say we create a
> "docs" repository under that.
>

The benefit of using plain GitHub over e.g. hugo is that you don't need
to host the site anywhere, GitHub (or GitLab) would do it for you :)


> I said in my email that I think more people are looking for long-form
> documentation (walkthroughs, tutorials, how-tos, etc) but that I also
> wanted to have a place to store other long-form content that isn't
> "how-to" content. But maybe we should find a way to keep some
> "wiki-like" topics too. Let's say we created 3 subdirectories inside
> this "docs" repository:
>
> 1. 'guides' for long-form content like how-tos, walkthroughs, and
> tutorials ("How to install FreeDOS," "How to set up networking," "How
> to get started on the command line," .. and other how-tos)
>
> 2. 'about' for other long-form content that is more like "what-is"
> content, like a copy of the FreeDOS Spec, the 1994 announcement, the
> original manifesto, .. things like that
>
> 3. 'info' for short-form information that's not a "help" page,
> basically the kind of topics we would have had on the wiki. Like a
> short page to say what "virtual machine "means, what "BIOS" is, things
> like that.
>
> Then everyone could contribute to that GitHub project, writing content
> in Markdown. I think we'd want to have a "style guide" so that we
> format things the same, but that's easy to do. (Like use '#' heading1
> for the title, 1-2 short paragraphs as an intro, then '##" heading2
> and '###' heading3 for section and subsection headings, .. keep it
> simple.)
>

Hugo (and I'm sure other static website generators do it too) has a page
template for this. We could have a base template also checked in, allowing
contributors to simply copy it for a quick start :)


> Contributing to the documentation in this way would be the same
> process as contributing to any other open source project hosted on
> GitHub. I'd suggest using a Creative Commons Attribution ShareAlike
> license.
>

One thing to keep in mind is that if we include code either from the
projects
or as part of an article, we should always clarify the licence of the
source code
in the article.


> We could also add a rule (style guide: "How to write FreeDOS how-tos
> in Markdown") that topics should only link to other topics in the same
> area - so 'info' topics can link to other 'info' topics. That would
> make it easy for authors to crosslink to [virtual machine](vm.md) for
> more information about virtual machines from an 'info' topic about
> "VirtualBox," or crosslink to [zip files](zip.md) from an 'info' topic
> about FreeDOS package files. Then you end up with the same effect as a
> wiki, but implemented through Markdown on GitHub.
>
> And if we ensure that files use 8.3 naming (vm.md instead of
> virtualmachine.md) that would make it easy to roll this into a
> "documentation" package to include in the FreeDOS distribution. As a
> quick implementation: we could automate a process to download a zip
> file of the "docs" repository from GitHub, use sed to change the
> ".md)" to ".htm)" link extensions in the text, run pandoc to convert
> every Markdown file to HTML, then zip it up again as a FreeDOS
> package.
>

I like this idea! I might copy this for DOG :D It seems that

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

On Fri, Jul 5, 2024 at 2:00 PM Wilhelm Spiegl  wrote:
>
> Could you offer a few spammed files for download so that the fd group can 
> check if the files can be fixed?
> How many files do we talk about?
>


From my other email, and the temporary page at
https://wiki.freedos.org/spammed/ with screenshots, I said it was
"hundreds and hundreds of new pages." But really it's thousands of
spam pages: see the screenshot from the Orphaned pages report, showing
500 pages at a time, sorted alphabetically, and over half of page 1 is
"pages that start with a number." Page 1 ends with "BBB," page 2 goes
to "Fiber," and page 3 goes to "Ideal." After 1,500 wiki entries,
we're only at "I" in the alphabet. So you can see that this is a
really long list of pages. And many hundreds of dummy users. But I
don't think they mangled any existing wiki pages, probably to stay
under the radar.

But there has to be a better way to manage documentation than using a
wiki. And I really liked Bernd's suggestion, see that discussion for
how that could work. I think copying/pasting an initial set of content
into Markdown wouldn't take too long.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

>> On Fri, Jul 5, 2024 at 1:21 PM Wilhelm Spiegl via Freedos-devel wrote:
>>
>> > I wonder how someone was able to come in? Bad configured server / not yet 
>> > fixed linux bug or bad password?
>> > Have I been pawned? shows interesting results for passwords.
>> >

> Am 05.07.24, 20:32 schrieb Jim Hall via Freedos-devel 
> :
>
>> My impression from managing the wiki when it was on SourceForge, and
>> moving the wiki to wiki.freedos.org, is that Mediawiki was designed to
>> be "everything for everyone." So it has a lot of entry points into the
>> system, which means a pretty wide attack surface for a system everyone
>> on the Internet can talk to.
>>

On Fri, Jul 5, 2024 at 1:44 PM Wilhelm Spiegl  wrote:
>
> Nevertheless it is strange to have the second attack within a few
> months (mail). I just tested it, you do not come into mailing list if
> you use an unknown mail address.
>


The reason for moving the wiki from SourceForge to wiki.freedos.org
wasn't because the old wiki was spammed or hacked. SourceForge had
been making some updates to the web hosting service, and basically
broke how the wiki worked. I moved the wiki to wiki.freedos.org so we
could have more control over the website.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

On Fri, Jul 5, 2024 at 1:21 PM Wilhelm Spiegl via Freedos-devel
 wrote:
>
> I wonder how someone was able to come in? Bad configured server / not yet 
> fixed linux bug or bad password?
> Have I been pawned? shows interesting results for passwords.
>

My impression from managing the wiki when it was on SourceForge, and
moving the wiki to wiki.freedos.org, is that Mediawiki was designed to
be "everything for everyone." So it has a lot of entry points into the
system, which means a pretty wide attack surface for a system everyone
on the Internet can talk to.


BTW, I also check https://haveibeenpwned.com/ every few months to
check for data issues, and you need to be thoughtful about what you
find there. For example, they show several "data breaches" for me that
weren't "account breaches." Like 'B2B USA Businesses' which aggregates
contacts lists for different employers in the US (they sell access to
that list to people like recruiters and marketers). My email was in
there because they collected it (and that data was leaked during a
data breach) but not because I had an account there. And then you have
things like the Linux Mint breach, and I set up an account there to
ask exactly one question on their board - but I didn't enter any
personal data, just email address and "Jim Hall" (any other fields
would have been blank or made-up data) so the other stuff in that
breach doesn't apply to me. A reminder to be careful about what data
you share online.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

On Fri, Jul 5, 2024 at 5:47 AM Eric Auer via Freedos-devel
 wrote:
>
>
> Hi Jim,
>
> sounds like somebody copied their whole spam wiki on top of our wiki?
>
> That means it barely got damaged, we only need a way to mass-delete
> their content, recognizable by originating from edits in a very small
> time window from many different accounts which all are very young.
>
> We need some wiki expert to suggest a tool to automate cleaning :-)


While I *think* the spammers "only" copied a bunch of their content
into other pages in our wiki, and *probably* didn't damage our pages
(such as to add links from "our" pages to "their" pages) we can't be
*sure* without looking at everything. That's a lot of pages.

And see also this note from my email. Maintaining a Mediawiki requires
a lot of work, and you have to patch to the latest version as soon as
it's available, and do that *immediately*, or we risk having this
happen again.

> Maintaining a Mediawiki requires a lot of work. You basically have to
> jump onto a new version as soon as they release a new one, because
> they often fix security issues (probably like the one that caused our
> problem). We were on the 1.41.x version, and the Mediawiki website*
> says "The 1.42.0 stable release came out on 27 June 2024." That was
> shortly after our wiki was spammed. I'm not excited about a future
> where I need to drop all my other work immediately, just to apply a
> new Mediawiki version to the wiki website.
> *see https://www.mediawiki.org/wiki/MediaWiki_1.42


I think there's a better way to manage documentation. I really like
Bernd's suggestion. See my reply to him about how to extend it - I
think that will cover all our use cases, and provide flexibility down
the road.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Eric Auer via Freedos-devel]

Hi Jim,

sounds like somebody copied their whole spam wiki on top of our wiki?

That means it barely got damaged, we only need a way to mass-delete
their content, recognizable by originating from edits in a very small
time window from many different accounts which all are very young.

We need some wiki expert to suggest a tool to automate cleaning :-)

Eric


https://wiki.freedos.org/spammed/





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki is temporary offline

[Jim Hall via Freedos-devel]

Hi everyone. I am following up on my email from a week ago, about the wiki.

To summarize: I discovered that our wiki had been spammed, but
fortunately I found it only a day after it was spammed.

I discovered the spamming on June 27, and immediately shut down the
wiki and emailed the freedos-user email list about it:

On Thu, Jun 27, 2024 at 10:37 AM Jim Hall  wrote:
>
> I just realized that someone started spamming our wiki yesterday. So
> I've taken that down until I can clean it out and apply a patch.
>
> Great. Just when a bunch of people would be likely to visit the wiki
> to learn more about us.

Unfortunately, the only backup was right before I started copying over
most of the content, and they spammed the site before the next backup
- and I had already made a ton of updates to the wiki in the weeks
leading up to the 30th anniversary on June 29. So rolling back to a
previous backup basically wipes out the wiki.

I can't attach screenshots on the email list, so I've created a
temporary page at https://wiki.freedos.org/spammed/ that has
screenshots and a version of this email.

Whoever spammed the wiki, I don't think they mangled any existing wiki
pages, probably to stay under the radar. That means our content is
still there, so we can copy/paste it out of the wiki.

I found out about the spammed wiki because I was searching for the
answer to a question someone asked me about the history of FreeDOS,
and I thought we had a "history" page. I deleted these first 3 pages
before I realized the extent of the spamming.

But they created hundreds and hundreds of new pages, most (all?) of
them not linked to from any other pages on the wiki (orphaned). They
also created many hundreds of dummy users.

The web page I linked to has a screenshot from the Orphaned pages
report, showing 500 pages at a time, sorted alphabetically, and over
half of page 1 is "pages that start with a number." Page 1 ends with
"BBB," page 2 goes to "Fiber," and page 3 goes to "Ideal." So you can
see that this is a really long list of pages.

Doing a spot check on these pages and looking at the creation date for
each, I'm pretty sure the hack happened a day or two before I found it
on June 27.


So, where do we go from here?

I could rebuild the wiki. However, that would require basically
rebuilding from scratch.

Maintaining a Mediawiki requires a lot of work. You basically have to
jump onto a new version as soon as they release a new one, because
they often fix security issues (probably like the one that caused our
problem). We were on the 1.41.x version, and the Mediawiki website*
says "The 1.42.0 stable release came out on 27 June 2024." That was
shortly after our wiki was spammed. I'm not excited about a future
where I need to drop all my other work immediately, just to apply a
new Mediawiki version to the wiki website.
*see https://www.mediawiki.org/wiki/MediaWiki_1.42

Even before this issue, I was thinking about how to integrate some of
our "non-wiki" content into the wiki website. For example, we have
some ebooks at https://www.freedos.org/books/ and content from the
press kit that I wanted to migrate into the wiki in some way - but
these aren't really "wiki" topics, they are longer form. And I wanted
to copy the articles I've written about FreeDOS into the wiki - but
again, these don't fit as "wiki" topics.

Years ago, we created a "FreeDOS Documentation Project" website that
hosted all of our "how-to" articles, "technotes," and other long form
topics. We retired that when SourceForge set up a shared wiki for all
projects hosted at SourceForge, and we thought it would be easier to
maintain a wiki. And for a time, that worked well, until most folks
stopped contributing to the wiki. We had a few who updated the wiki,
but like two or three people, including me. And of course: later,
SourceForge stopped managing a shared wiki, and that's when we set up
our own wiki (which lived on freedos.sourceforge.net for a long time
before SF did an update that broke the wiki and I had to move the wiki
to the new server).

Looking at how people look for "help" today, I don't think a wiki is
the right answer in 2024. We've seen people email freedos-user and
freedos-devel to ask for help, and I've seen similar requests on
Facebook and on YouTube sometimes. What people are looking for is a
"walkthrough" or a "tutorial" - long form "how-to" content that shows
people how to do something, like how to install FreeDOS, or how to use
the FreeDOS command line. Instead of building a new wiki, I think this
is the right opportunity to set up a FreeDOS "documentation" website,
filled with these kinds of "how-to" and "what-is" content.

Writing about FreeDOS is also my strength, so I can build up some core
documentation quickly by adapting (or just copying/pasting) content
from articles I've already written, such as the articles I wrote for
Opensource.com and Both.org and elsewhere. The website would be an
excellent place for anyone who wants to write a 

[Freedos-devel] FreeDOS Interim Build T2407

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2407 for July is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes since T2406:

2024-06-30 18:44:34 v8power (shidel): VVIEW added DirectVideo Support and 
removed scrolling for Page Up/Down
2024-06-30 09:38:58 project_FD-NLS (shidel): report update
2024-06-30 05:43:22 project_FD-NLS (shidel): Merge branch 'master' of 
github.com:shidel/fd-nls
2024-06-29 20:19:10 project_FD-NLS (shidel): new VVIEW utility in V8Power Tools
2024-06-29 11:54:53 v8power (shidel): updated to v2024.06.29
2024-06-26 05:41:08 project_FD-NLS (shidel): added VREADKEY to V8PowerTools
2024-06-25 19:50:06 v8power (shidel): v2024.06.25
2024-06-24 07:25:39 dog (shidel): updated to v0.8.4b
2024-06-24 06:01:24 jwasm (shidel): updated to v2.18
2024-06-24 05:46:37 debug (shidel): updated to v2.50
2024-06-23 22:51:03 zoo (shidel): update metadata
2024-06-23 21:22:42 ambread (shidel): updated to v20240131
2024-06-23 14:20:27 project_FD-NLS (shidel): Merge pull request #192 from 
cardpuncher/master
2024-06-23 13:46:11 v8power (shidel): upx compressed executables
2024-06-23 10:37:55 project_FD-NLS (cardpuncher): Add files via upload
2024-06-23 06:11:16 v8power (shidel): v2024.06-23 - Fixed 486 CPU identification
2024-06-22 18:24:08 project_FD-NLS (shidel): updated V8Power Tools build 
requirements
2024-06-22 15:02:06 v8power (shidel): missing translation/help files
2024-06-06 11:10:39 mistral (shidel): corrected package version number

I finally made time to dig into the V8Power Tools VINFO program regarding the 
incorrect identification of some 486 processors as a 80186. It was a typo under 
the value assigned to 486 processors that do not support the CPUID instruction. 
All seems good now. Because of that issue, the current floppy installer only 
uses the information to select the config file. However, it assumes anything 
less than a i386 has been misidentified and overrides the detection to always 
install the package set for a i386 or better CPU. For T2408, I will remove 
override in the Floppy Installer so lesser hardware does not have useless 
packages installed. The Floppy Edition has always had the ability for the user 
to override detection and install for any specific CPU level through command 
line options. 

I also just wanted to mention the new VVIEW utility that is part of V8Power 
Tools. It is a simple text viewer limited to 2GB files and supports CRLF, LF 
and CR line endings. It also supports “windowed” viewing of text inside 
“framing” like the other V8Power Tools. In theory, the FreeDOS installer could 
now be updated with a “view readme” on the “welcome” screen which then could be 
displayed in a box without appearing to leave the installer. 

:-)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS virtual get-together [happening soon!]

[Jim Hall via Freedos-devel]

Hi everyone!

This is a reminder that the FreeDOS virtual get-together is in about
half an hour from now. We usually do these on Sundays, but today is
the 30th anniversary day, so we had decided to do it today instead.

Here's the connection info:

FreeDOS virtual get-together (social)
Saturday, June 29 · 11:00am – 12:00pm
Time zone: America/Chicago

Google Meet joining info
Video call link: https://meet.google.com/kst-xbvs-vya

Or dial: ‪(US) +1 978-378-5658‬ PIN: ‪655 995 894‬#
More phone numbers: https://tel.meet/kst-xbvs-vya?pin=3315499233403


See you there!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Runtime

[Rugxulo via Freedos-devel]

Hi,

(Sorry for being late to this discussion, I'm a bit backlogged.)

On Thu, May 2, 2024 at 7:05 PM Jim Hall via Freedos-devel
 wrote:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
>  wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?

The latest version of Jim's on iBiblio appears to be 2.1d from 2005.

It has a "Borland TC makefile" using "-mm" (medium model? why?) and
-DNDEBUG in addition to linking to Kitten. The .EXE is 26 kb,
presumably UPX'd, and I'm guessing it uses floating point emulation
(which is unlikely to help much and is extra bloat that is totally
unnecessary for any Pentium or newer FPU-having cpus).

Not trying to nitpick (I've also been looking at old code of mine from
2013 called TIMEIT.C), but just FYI 

1). his code isn't ANSI C89
= why include dos.h or process.h ? it says for exec() but uses
spawnvp(), I would normally prefer system()
= does that save memory? are we intentionally trying to avoid shelling
out to %COMSPEC% except for .BATs or built-ins?
= CLK_TCK is not ANSI (old 1988 POSIX???) and not at all preferred,
use CLOCKS_PER_SEC

2). Borland does use 64 kb of heap by default in the smaller data
models. To avoid that (and save a bit of memory, esp. since we're
shelling out), put "extern unsigned _heaplen = 1024;" and "extern
unsigned _stklen = 8192;" in your source. Try shelling out "mem /c" to
see the difference. (Maybe this is why he randomly chose "-mm" Medium
model?? Unnecessary, I'd just use Small.)

3). You really don't need printf() at all here (okay, maybe only for
Kitten ??). It doesn't matter as much for Turbo C, but even for
OpenWatcom it's like 6 kb. If you don't need floating point (see
below), you can make do with a simple "writelong()" routine and save
space. (Yes, I wrote such a routine, if you need it.) FYI, clock_t is
usually a typedef to a "long" integer.

4). In my program, I included both clock() and difftime(). My memory
(and notes) indicate that clock() was for integer times. You know, for
most simple uses, a round number of seconds elapsed is good enough
(and faster / smaller, no bloated and slow emulation lib or expensive
FPU needed). How often does 11 secs. versus 11.5 seconds matter?? A
naive Google search shows people advising to cast it to double! But
that defeats the whole point, IMHO. All the compilers I checked (about
a dozen) all have an integer value for CLOCKS_PER_SEC ... except Turbo
C! There it's 18.2 (for no good reason). Quick: undefine that and
redefine it to 18, that's good enough, IMHO. Or just use OpenWatcom.

> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-)

The 2012 version on iBiblio pointed to by Fritz was my unofficial hack
with EO (Esperanto) support.

Checking the latest "2024" version hosted online, it only adds HU but
omits EO. (That's fine if no one cares, but it feels like a
regression.)

> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.

2.1d from 2005 uses Kitten. The MAKEFILE.TC says this:

LDLIBS=kitten-b\kitten.obj

> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)

Most of that bloat can be removed in one of two ways:

1). use TC's -f87 or WCL's -fpi87 (mandatory hardware floating point
usage, no emulation)
2). use TC's -f- (avoid floating point entirely) only with
integer-friendly clock() and printf("%ld") code

> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements.

A naive way would be to use "PROMPT $t" and leave a TEST.BAT without
any "@echo off", and just calculate the difference shown in your head.

FreeCOM also (non-standard) supports "time /t" to print the current time.

> There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around

I forget what 4DOS uses. Some programming languages (e.g. QBASIC and
REXX) have easy timing built-in. DJGPP always had "REDIR.EXE -t", and
DJGPP's port of BASH has the standard *nix shell built-in "time"
command. (DJGPP's libc also has uclock() which tries to use Pentium's
RDTSC or automatically falls back to something else via SIGILL if that
fails).

> I'm in favor to swap out the old Runtime with this Runtime. No issues here.

One minor enhancement would be to consider stderr 

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Rugxulo via Freedos-devel]

Hi,

On Mon, Jun 17, 2024 at 6:41 PM Jim Hall via Freedos-devel
 wrote:
>
> You might be interested in this video I recorded yesterday about
> running FreeDOS on the Pocket386:
> https://www.youtube.com/watch?v=2h96UseZs6Q
>
> It shows several apps and games on the Pocket386, mostly running some
> shareware games, plus Word for DOS, and As Easy As spreadsheet.

Definitely cool. More videos of testing would be interesting.

Try rebuilding the FreeDOS kernel with OpenWatcom on it, heh.

Or install ZipSlack [Slackware 11, 2006??] Linux atop your FAT
partition, I think it supports 8 MB of RAM. (Seriously, people always
suggest an old Linux distro instead of DOS, but I think that's not
realistic in most ways. Still, no worse than trying to run ancient
Windows 3.1.)

> If you're curious about its performance, here's a quick rundown of some
> games and apps: [not all of these are shown in the video]
>
> Games:
>
> - Doom - runs fine at small size

I did leave a comment suggesting Fastdoom from Github, which has been
specifically optimized for 386s and 486s.

* https://github.com/viti95/FastDoom

> - Duke Nukum - runs fine, uses PC speaker

3D, right? Not the original 2D one?

> - Rise of the Triad - runs fine at small sizes, uses AdLib for sound

I forgot this was 386 DOS4GW. (It's based upon an improved Wolf 3D
engine, which was 286 / VGA.) I assume Wolf 3D would run faster but
maybe not. Hmmm, I vaguely recall some OpenWatcom 386 rebuilds of Wolf
3D.

* https://github.com/TobiasKarnat/Wolf4GW

> - Shadow Warrior - doesn't run (requires 9MB, this has 8MB)

I have no idea. DOS4GW 1.97 is limited in total RAM available, but it
does supposedly support VM swapping. But maybe they disabled that here
(and/or it's too slow to be usable). You could also try "CWSTUB
blah.exe" which supports swapping, but that may not work.

> - Tomb Raider - crashes during setup (not a surprise, this is a 1996
> game and requires way more memory and CPU than this laptop has - the
> game should have done a memory check)

I don't think the Pentium (1993 debut) was really widespread even in
1996 (too expensive), but indeed it was much faster. But I also don't
think a lot of things were optimized for legacy hardware (actual 386s)
even back then. Quake (1996) has no chance on this machine, for
instance.

> - Wolfenstein 3D - runs great!

Oh, okay, you did test this (it wasn't shown in the video).

> - Biomenace - runs fine

286 / EGA, I love that game!

> Apps:
>
> - Borland Turbo C++ compiler - editor runs fine, I've used the
> compiler to write a few test programs, no issues there

It seems quaint, but back in the day they told us the "optional" math
coprocessor was an unnecessary expense and "wasn't needed" unless we
were going to do a lot of scientific calculations. Normal home users
didn't "need" it. (And of course every cpu since the Pentium has it
included by default, go figure. Some software like GCC always assumed
an FPU present.)

Even ignoring that, the 386 itself was not pipelined like the 486, so
the fastest instruction was like 2 clocks. So a comparably-clocked 486
(40 Mhz) would, in theory, run twice as fast. Also 486s often had
(very small) on-chip caches which helped. But as far as cpu
instructions, the 486 only offered very little advantage.

Some expert (Michael Abrash??) once said that the 8086 and 386
preferred small code while the 486 was very sensitive to (code and
data) alignment and preferred more RISC-y simpler unrolled code. I'm
far from an expert, but docs always warned about AGI stalls and using
suboptimal code sequences, even suggesting "blended" code (or separate
code paths for distinct cpus).

One thing that always bugged me was how much slower GCC (DJGPP) got in
later versions after 2.7.2.1. That version ran okay on my 486, but
later versions like 2.95.3 (even with -O0) ran much slower. In the
race to constantly upgrade to newer hardware, a lot of software was
just never optimized properly because nobody cared enough. In fact, I
recall that GCC claimed that their 486 code was just the exact same
386 code only with extra alignment. Sad, really, that it never got the
full support it deserved. (You can actually rebuild GCC 2.7.2.1 in
DOS, I've done it. On my old Pentium it took about 10 minutes. I miss
the days when things were simpler and faster!) I don't think GCC even
got Pentium support until later (2.8.1). Pentium-scheduled code (U and
weaker V pipes) was a big improvement on those machines (and no huge
slowdown on older cpus).

Not everything can be "fixed" or optimized to run at lightning speeds
on such machines, but at least some noticeable improvements are
definitely possible.

Seriously, most code is just suboptimal, and without proper testing on
old hardware you'll never be aware of it.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Rugxulo via Freedos-devel]

Hi,

On Mon, Jun 17, 2024 at 6:42 PM Jim Hall via Freedos-devel
 wrote:
>
> I wrote a "how-to" article about FreeDOS on the Pocket386 for
> Both.org, but I also copied/pasted this into a wiki article on the
> FreeDOS wiki:
>
> Now that I've reinstalled the Pocket386, my next step is to test every
> application and game from FreeDOS T2406. If you're curious how an app
> performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
> I'll share notes in a follow-up thread.

Definitely interesting!

Since I don't have working legacy hardware anymore, I've done some
light, informal benchmarking of various tools under DOSBox-X (a "fast
486") in FreeDOS. It's definitely eye-opening (compared to my
semi-modern 2010 laptop). So things which seem instantaneous natively
run much slower when emulated. (This is actually good and lets me
optimize my code and compare compilers.)

> So far, I can report that FED is a bit slow to start up (just when I
> thought it had hung, it came up) but runs fine after that.

Is it UPX'd? LZMA compression is horribly slow on legacy cpus, that's
why it's disabled for 16-bit .EXEs by default. (Yes, I know this is a
32-bit DJGPP build.) If so, try unpacking and repacking with "--best"
instead.

A while back I tried running Linux under the web browser in a
Javascript-based emulator. It had GNU Emacs on there. Emacs took at
least a minute to boot up, but at least the syntax highlighting looked
pretty!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Michael Brutman via Freedos-devel]

I have a report from somebody who has used mTCP with an NE2000 type card on
the machine through the adapter - it worked.

SLIP or PPP through the serial port should also work fine.


On Mon, Jun 17, 2024 at 6:47 PM Jerome Shidel via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
>
> On Jun 17, 2024, at 9:27 PM, Jim Hall via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>
> 
>
>
> Jerome Shidel asked:
>>
>> Does that machine have a NIC and did you get it working under FreeDOS?
>>
>
>
> It has a ribbon cable to connect ISA but I don't have an Ethernet card to
> try, so I don't have networking running. It's standalone, just like my 386
> from my undergraduate days. :⁠-⁠)
>
>
> How about a modem?
>
> I think all my machines from 286 through Pentium 4 all had hardware
> modems. I even have 2 different PCMCIA modems laying around here for it
> somewhere.
>
> Then you could dial up a BBS… that is if you can find one. You may need to
> run your own.
>
> I also recall having some cable that would connect two machines. Possibly
> either over the parallel or serial ports. I think it may have been some
> Symantec product. Possibly called LAP-LINK or something like that. But, I
> honestly don’t ever remember using it.
>
>
>
> _______
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
> _______
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Jerome Shidel via Freedos-devel]

> On Jun 17, 2024, at 9:27 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> 
> 
> 
>> Jerome Shidel asked:
>> 
>> Does that machine have a NIC and did you get it working under FreeDOS?
> 
> 
> 
> It has a ribbon cable to connect ISA but I don't have an Ethernet card to 
> try, so I don't have networking running. It's standalone, just like my 386 
> from my undergraduate days. :⁠-⁠)

How about a modem? 

I think all my machines from 286 through Pentium 4 all had hardware modems. I 
even have 2 different PCMCIA modems laying around here for it somewhere. 

Then you could dial up a BBS… that is if you can find one. You may need to run 
your own. 

I also recall having some cable that would connect two machines. Possibly 
either over the parallel or serial ports. I think it may have been some 
Symantec product. Possibly called LAP-LINK or something like that. But, I 
honestly don’t ever remember using it. 


> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Jim Hall via Freedos-devel]

Jerome Shidel asked:
>
> Does that machine have a NIC and did you get it working under FreeDOS?
>


It has a ribbon cable to connect ISA but I don't have an Ethernet card to
try, so I don't have networking running. It's standalone, just like my 386
from my undergraduate days. :⁠-⁠)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Jun 17, 2024, at 7:42 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> Also:
> 
> I wrote a "how-to" article about FreeDOS on the Pocket386 for
> Both.org, but I also copied/pasted this into a wiki article on the
> FreeDOS wiki:
> 
> https://wiki.freedos.org/wiki/Pocket386
> 
> Basically, it's these steps:
> 
> 1. transfer the CF card to my Linux box
> 2. boot the install LiveCD in QEMU, using '-hda /dev/sda' to use the CF card
> 3. exit to DOS, do these steps manually:
> 4. FDISK (then reboot)
> 5. FORMAT C:
> 6. SYS C: /FORCE:CHS
> 7. SETUP ADV
> 8. do the rest of the install in the installer, but skip the step to
> transfer system files
> 9. transfer the CF card back to the Pocket386
> 
> 
> If you want to skip all of that: this afternoon, I reinstalled FreeDOS
> T2406 on this laptop, using a "Full installation including
> applications and games" (with source code). I've shared an image of my
> CF card here:
> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/pocket386/
> 
> That's not really a "distribution" per se, but I couldn't think of a
> better place to store a 328MB file. Might move it later.
> 
> 
> Now that I've reinstalled the Pocket386, my next step is to test every
> application and game from FreeDOS T2406. If you're curious how an app
> performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
> I'll share notes in a follow-up thread.
> 
> So far, I can report that FED is a bit slow to start up (just when I
> thought it had hung, it came up) but runs fine after that.
> 
> Jim

I suspect anything that is either CPU or I/O intensive is going to be slow. 

Does that machine have a NIC and did you get it working under FreeDOS?




> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Jim Hall via Freedos-devel]

Also:

I wrote a "how-to" article about FreeDOS on the Pocket386 for
Both.org, but I also copied/pasted this into a wiki article on the
FreeDOS wiki:

https://wiki.freedos.org/wiki/Pocket386

Basically, it's these steps:

1. transfer the CF card to my Linux box
2. boot the install LiveCD in QEMU, using '-hda /dev/sda' to use the CF card
3. exit to DOS, do these steps manually:
4. FDISK (then reboot)
5. FORMAT C:
6. SYS C: /FORCE:CHS
7. SETUP ADV
8. do the rest of the install in the installer, but skip the step to
transfer system files
9. transfer the CF card back to the Pocket386


If you want to skip all of that: this afternoon, I reinstalled FreeDOS
T2406 on this laptop, using a "Full installation including
applications and games" (with source code). I've shared an image of my
CF card here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/pocket386/

That's not really a "distribution" per se, but I couldn't think of a
better place to store a 328MB file. Might move it later.


Now that I've reinstalled the Pocket386, my next step is to test every
application and game from FreeDOS T2406. If you're curious how an app
performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
I'll share notes in a follow-up thread.

So far, I can report that FED is a bit slow to start up (just when I
thought it had hung, it came up) but runs fine after that.

Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS on Pocket386 (follow-up)

[Jim Hall via Freedos-devel]

You might be interested in this video I recorded yesterday about
running FreeDOS on the Pocket386:
https://www.youtube.com/watch?v=2h96UseZs6Q

It shows several apps and games on the Pocket386, mostly running some
shareware games, plus Word for DOS, and As Easy As spreadsheet. If
you're curious about its performance, here's a quick rundown of some
games and apps: [not all of these are shown in the video]

Games:

- Dark Forces - runs a bit slow (but no SB16)
- Doom - runs fine at small size
- Duke Nukum - runs fine, uses PC speaker
- Ford simulator - runs great!
- Jill of the Jungle - runs great, full music and sound, sometimes has
glitchy video in VGA but no problems in EGA
- Pinball - runs great!
- Rise of the Triad - runs fine at small sizes, uses AdLib for sound
- Simple Senet - runs great!
- Shadow Warrior - doesn't run (requires 9MB, this has 8MB)
- Tomb Raider - crashes during setup (not a surprise, this is a 1996
game and requires way more memory and CPU than this laptop has - the
game should have done a memory check)
- Wolfenstein 3D - runs great!
- Biomenace - runs fine
- Commander Keen - Keen1-5 all work great!

Apps:

- Ability Office - runs great!
- As Easy As - runs great!
- Borland Turbo C++ compiler - editor runs fine, I've used the
compiler to write a few test programs, no issues there
- Word - runs great!


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[tom ehlert via Freedos-devel]

Hallo Herr Bernd Böckmann via Freedos-devel,

am Freitag, 7. Juni 2024 um 13:46 schrieben Sie:



>> Am 04.06.2024 um 00:24 schrieb Eric Auer via Freedos-devel 
>> :
>> 
>> 3. Or we could give SYS support for multi-sector FAT32 boot
>> sectors, which would be necessary for automatic switching
>> on FAT32. Only FAT16 is simple enough to handle both cases
>> within a single sector.

> Thinking again about the problem, wouldn't it be an option to always install 
> the CHS loader if the partition to boot from is within the first 1024 
> cylinders? That would have mitigated the problem on the Book386.

This would have mitigated the (very rare) case of installing a disk installed 
on LBA, but moved to CHS only machine.

But would create new problems when moving from one CHS machine to another CHS 
machine with different *virtual*
CHS section for the same disk. BIOS's were free to and indeed did translate the 
same disk to different *virtual* 
CHS parameters, where LBA addressing solved the problem.

Eric is right.

in the meantime Jim knows the solution. When buying 386 class machines you are 
entitled to enjoy all the 
hidden problems from the time of 386 machines. That's part of the experience;)

Tom





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi Bernd,


Thinking again about the problem, wouldn't it be an option to always
install the CHS loader if the partition to boot from is within the
first 1024 cylinders? That would have mitigated the problem on the
Book386.


Earlier in this thread, I explicitly suggested to NOT use CHS
unless absolutely necessary. For example when you install on
one PC and then transplant the disk to another PC, the geometry
can change, but LBA will have no problems with that as long as
both PC support LBA at all.

So LBA is the safer option in almost all cases, the only exception
being installing on LBA-enabled PC or VM and then transplanting to
computers without LBA support.

Thinking about that, is it possible to disable LBA in popular VM?

Then we could tell those few users who want to use a VM to prepare
a disk for transplantation to another, non-LBA PC, to just do that.

Maybe they could even tell the VM to use the same CHS geometry as
they have seen when the same disk was installed in the non-LBA PC?

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Bernd Böckmann via Freedos-devel]

> Am 04.06.2024 um 00:24 schrieb Eric Auer via Freedos-devel 
> :
> 
> 3. Or we could give SYS support for multi-sector FAT32 boot
> sectors, which would be necessary for automatic switching
> on FAT32. Only FAT16 is simple enough to handle both cases
> within a single sector.

Thinking again about the problem, wouldn't it be an option to always install 
the CHS loader if the partition to boot from is within the first 1024 
cylinders? That would have mitigated the problem on the Book386.

Bernd



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Jeremy wrote:
> I'm thinking of adding a multi-sector boot code for fat32 to support
> both LBA and CHS, but possibly keeping the single sector boot code
> support as well.   It would be a build option along with other
> advanced features so as to not bloat basic sys included with kernel
> archive.  I'd like to see if I can still keep lba logic in 1st sector
> so if 2nd sector corrupted could still boot in happy path (lba no
> errors).  A 3rd sector would not be used hopefully.   I will see
> about working on this, but not until next week.
>
> I don't think anything needs to be done with installer.  But we
> can document potential issues and fixes when moving drives from one
> computer to another, ie boot sector may need updating and there may
> be other issues if chs used and different geometry expected.
>


FYI to anyone who is curious:
I'm planning to do a video for the YouTube channel with this device in
the next few days. I figure it's good to show FreeDOS running on real
hardware, especially a "retrocomputing" laptop like this. After that
(probably this weekend) I'll start over and install a "Full" (all
applications and games) version of FreeDOS, using the T2406 test
release.

My goal is to run *every* app and program from the distribution on the
Pocket386. I expect everything will be fine, but some apps may be slow
(and that might be expected for "developer" apps like compilers or
something). I'll report back on freedos-devel with anything odd that
comes up.

If you want me to test something specific, please reply here and I'll
add that to the list of things to do.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[perditionc--- via Freedos-devel]

On Mon, Jun 3, 2024, 6:26 PM Eric Auer via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
> Hi Jim,
>
> from an engineering point of view, I would say LBA avoids
> problems related to mismatching CHS geometries on different
> computers, so I still prefer the MANUAL method where users
> have to run SYS C: /FORCE:CHS before transplanting a disk
> from a computer with LBA support to one without LBA. I would
> recommend to avoid CHS on all computers which support LBA.
>
> 1.

...

>
> 3. Or we could give SYS support for multi-sector FAT32 boot
> sectors, which would be necessary for automatic switching
> on FAT32. Only FAT16 is simple enough to handle both cases
> within a single sector.
>
> While FAT32 does support multi-sector boot sectors, I would
> think that those get more easily damaged than single sectors?
>
> Regards, Eric
>
>
>
> > So that says that QEMU supports LBA but the BIOS on the Pocket386 does
> > not. And ...
>


I'm thinking of adding a multi-sector boot code for fat32 to support both
LBA and CHS, but possibly keeping the single sector boot code support as
well.   It would be a build option along with other advanced features so as
to not bloat basic sys included with kernel archive.  I'd like to see if I
can still keep lba logic in 1st sector so if 2nd sector corrupted could
still boot in happy path (lba no errors).  A 3rd sector would not be used
hopefully.   I will see about working on this, but not until next week.

I don't think anything needs to be done with installer.  But we can
document potential issues and fixes when moving drives from one computer to
another, ie boot sector may need updating and there may be other issues if
chs used and different geometry expected.

Jeremy

>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi Jim,

from an engineering point of view, I would say LBA avoids
problems related to mismatching CHS geometries on different
computers, so I still prefer the MANUAL method where users
have to run SYS C: /FORCE:CHS before transplanting a disk
from a computer with LBA support to one without LBA. I would
recommend to avoid CHS on all computers which support LBA.

1. Of course you could create a menu item in the installer to
let advanced users force CHS mode, but everybody who is able
to transplant a disk or diskimage can easily run SYS by hand.

2. We could also tell the installer to create a FAT16 boot and
a FAT32 data partition, because our FAT16 boot sector can
automatically switch to CHS or LBA depending on availability,
but that would be less elegant and may confuse the users.

3. Or we could give SYS support for multi-sector FAT32 boot
sectors, which would be necessary for automatic switching
on FAT32. Only FAT16 is simple enough to handle both cases
within a single sector.

While FAT32 does support multi-sector boot sectors, I would
think that those get more easily damaged than single sectors?

Regards, Eric




So that says that QEMU supports LBA but the BIOS on the Pocket386 does
not. And that is probably why installing to the CF card from QEMU
worked fine .. and booting the CF card in QEMU worked fine .. but when
I just did plain "SYS C:" from the QEMU environment, FreeDOS didn't
boot on the Pocket386 (because it was trying to use LBA, which is not
supported on the Pocket386). When I instead used "SYS C: /FORCE:CHS"
from the QEMU environment, FreeDOS booted fine on the Pocket386
(because it was using CHS).

If you can think of a good engineering workaround for that, please do
it. But I'm thinking this is a "user" issue. I had SYS'd the drive
from a different "computer" (QEMU) then moved the CF card to a
different computer to boot it there. And then we run into BIOS not
supporting LBA on the second system.






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Eric Auer wrote:
> >
> > Are you sure that this is not just what the PARTITION TABLE says?
> > Is there a way to ask FDISK whether it detects BIOS LBA support?


Bernd Böckmann wrote:
> Eric is right, I had a look at the relevant lines of the FDISK
> source. This is only an indicator that FDISK generally makes use of LBA,
> not if LBA for the currently selected disk is actually supported. Two
> different things.
>
> Sorry for that. Had better looked this up by myself before suggesting
> it.
>
> I now altered FDISK so that it also shows if LBA is actually used. It
> is printed after the disk size in the main menu if started with /XO.
>
> Jim, you may download the new executable from
[..]

Thanks! I grabbed that and ran the new FDISK with /xo on the CF card,
running in two ways:

1. Booted in QEMU, using the CF card (see command line in previous
emails). The output shows:

> Current fixed disk drive: 1   1775 Mbytes (LBA)

2. Put the CF card in the Pocket386 and booted from that. The output shows:

> Current fixed disk drive: 1   1775 Mbytes (CHS)


To compare: I also ran the new FDISK with /xo in the QEMU environment
where I normally run FreeDOS T2406 on my Linux box. That has a 500MB
"C:" drive (qcow2 disk image). The output there shows:

> Current fixed disk drive: 1   499 Mbytes (LBA)


So that says that QEMU supports LBA but the BIOS on the Pocket386 does
not. And that is probably why installing to the CF card from QEMU
worked fine .. and booting the CF card in QEMU worked fine .. but when
I just did plain "SYS C:" from the QEMU environment, FreeDOS didn't
boot on the Pocket386 (because it was trying to use LBA, which is not
supported on the Pocket386). When I instead used "SYS C: /FORCE:CHS"
from the QEMU environment, FreeDOS booted fine on the Pocket386
(because it was using CHS).

If you can think of a good engineering workaround for that, please do
it. But I'm thinking this is a "user" issue. I had SYS'd the drive
from a different "computer" (QEMU) then moved the CF card to a
different computer to boot it there. And then we run into BIOS not
supporting LBA on the second system.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Bernd Böckmann via Freedos-devel]

> Am 02.06.2024 um 23:55 schrieb Eric Auer via Freedos-devel 
> :
> 
> Are you sure that this is not just what the PARTITION TABLE says?
> Is there a way to ask FDISK whether it detects BIOS LBA support?

Eric is right, I had a look at the relevant lines of the FDISK source. This is 
only an indicator that FDISK generally makes use of LBA, not if LBA for the 
currently selected disk is actually supported. Two different things.

Sorry for that. Had better looked this up by myself before suggesting it.

I now altered FDISK so that it also shows if LBA is actually used. It is 
printed after the disk size in the main menu if started with /XO.

Jim, you may download the new executable from

https://gigamove.rwth-aachen.de/en/download/46a8e5e091623614e88bb4f6b6391d83


Bernd



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi Jim,


To Jim: Are you sure you ran FDISK /XO on the Pocket386 system? If FDISK
says it detects LBA there but the LBA loader from FreeDOS doesn't work
that'd be quite the bug.



Definitely I'm seeing "W95B INT LBA FAT32" when running FDISK /xo on
the Pocket386. I can't send photos to the email list, but I'll send an
off-list email to you and Bernd with a photo.


Are you sure that this is not just what the PARTITION TABLE says?
Is there a way to ask FDISK whether it detects BIOS LBA support?

A bit weird, but maybe useful as a compatibility test: You could
use SYS CONFIG to manipulate CHS/LBA mode flags in kernel binaries
to force the kernel to use either CHS or LBA. Do both work on the
Pocket386? If yes, then only the LBA boot sector has an issue, not
LBA support of the Pocket386 in general.

Maybe you have other ideas for testing. Note that it can render
your install unbootable if you force the kernel to use a mode
not properly supported by the BIOS, but I think you know how to
repair such situations :-)

I am sure we also have better tools to show what the BIOS says
about CHS and LBA support and disk properties. Suggestions please!

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Jim Hall wrote:
> >> 5. SYS C: /FORCE:CHS
> >>
> >>
> >> And that boots without problem on the Pocket386!
> >>
> >>
> >> Also: you asked about FDISK /XO output. It reports "W95B INT LBA
> >> FAT32" in the upper left corner. This is running FDISK 1.3.15.

E. C. Masloch wrote:
> To Jim: Are you sure you ran FDISK /XO on the Pocket386 system? If FDISK
> says it detects LBA there but the LBA loader from FreeDOS doesn't work
> that'd be quite the bug.

Definitely I'm seeing "W95B INT LBA FAT32" when running FDISK /xo on
the Pocket386. I can't send photos to the email list, but I'll send an
off-list email to you and Bernd with a photo.


[..]
> If it really turns out that FDISK /XO detected LBA support *on the
> Pocket386* but the LBA loader fails, I could cough up some debugging
> hints as to how to install bootable lDebug on the system then debug the
> failing loader. For instance:
>
> 1. Rename kernel.sys to fdkernel.sys (exact name doesn't matter)
> 2. Copy ldebug.com to working drive (using CHS loader) as kernel.sys
> 3. Boot lDebug
> 4. Boot FreeDOS using "BOOT PROTOCOL FREEDOS fdkernel.sys" then "Q"
> 5. Write loader to file: "SYS C: /BOOTONLY /FORCE:LBA BOOTSECT.DOS"
> 6. Reboot into lDebug
> 7. Try "BOOT PROTOCOL CHAIN" and then trace the loader
>
> You could install the FAT32+FSIBOOT loader for lDebug as well but when
> you already have a working boot loader then this would just be the
> possible cause of more headaches. Not impossible, but not worth it
> probably. As I have oft repeated lDebug can be loaded as a number of
> kernel formats, most recently including the FreeDOS and the original
> Enhanced DR-DOS (v7.01.07) kernel load formats.
>
> I will advertise the lDOS FAT32 loader more in another subsequent email.
>

I'm happy to do any debugging you need on this device. I bought this
so I could experiment with it - so I don't mind reinstalling the
system, running debugging tools, or doing whatever we need to get more
info about it.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi!


It would be possible to add an additional screen to the installer
(probably only advanced mode) to use the /FORCE:CHS option.


That would be a good option to have, but I'd like to fix sys 
bootcode  so

lba code works and maybe make a multi sector fat32 version that supports
both chs & lba...


If you SYS on the same system where you work later, SYS will
detect whether or not there is FAT32 support.


I think you meant "LBA support" in this line. And indeed it does, but 
this doesn't work as intended if the target system doesn't support LBA 
but the installer system does.


Correct. I think this is sufficiently advanced (people who
install to a disk/image on one system, then copy it to some
other system) that it is okay to expect such users to do a
manual SYS /FORCE:CHS at some point on the installer system.

Also, the exciting other question is whether that Pocket386
supports LBA, but maybe in some incompatible way. Because in
that case, there would be a problem worth addressing in code.

If Pocket386 simply does not support LBA at all, then problems
only happen when users "transplant" LBA installs to non-LBA 386.

Which they may HAVE to do if there is no easy way to install by
booting some installer on the Pocket386 itself, but that would
be yet another, third topic to discuss ;-)

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Deposite Pirate via Freedos-devel]

On 6/2/24 1:55 AM, Jim Hall via Freedos-devel wrote:

Jim Hall wrote:

My CF card reader arrived, so I tried installing FreeDOS on the CF
card. I've had partial success; I can install, but I can't boot. I
need help.


[..]

I've also tried running QEMU directly against the CF card, in case
something weird happened when I was trying to write the CF card. So I
did this:

$ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


And that FreeDOS install works fine too. Same as step 3. But it hangs
at "Loading FreeDOS" when I boot the Pocket386 with the CF card.



I just did another test, one I should have tried first:


1. Ran QEMU directly against the CF card (same QEMU command line as above)

2. Did *not* run the installer

3. Manually ran FDISK, delete all partitions

4. Reboot .. run FDISK, create a single 10MB partition

5. Reboot .. FORMAT C: /s


And then I put the CF card back into the Pocket386, and it boots!
There's nothing there (I didn't install, just made a tiny partition
bootable) but at least it works!!

So I'll do more work with this tomorrow and put FreeDOS on it, even if
I have to do everything without the installer.


(I don't think the installer is specifically at fault, probably something else.)


This is normal with new CF cards and/or some CF adapters. I use a lot of 
CF cards on various old computers and they never work until you "fdisk 
/mbr" them for some reason. Just dd'ing with Linux doesn't work. It's 
not a problem with the Pocket386.


--
WWW: https://metalpunks.info
GPG: 0x22AC1231



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[E. C. Masloch via Freedos-devel]

On at 2024-06-02 13:31 +0200, Bernd Böckmann via Freedos-devel wrote:


If the 10MB partition can be booted from, we have to take into account that 
this is a FAT16 partition, and accordingly the FAT12/16 volume boot code is 
installed. This supports both LBA and non-LBA access.

Jim, can you upload the non-working image and the working 10MB test image, so I 
can have a look at the relevant data structures (MBR etc.)?

https://nextcloud.iww.rwth-aachen.de/index.php/s/BRXqZDGasw74NN9

What BIOS is this machine using?

As Jerome said, the FreeDOS installer will re-use an existing partition layout. 
So what you can try (not 100% sure you already did that): start with an empty 
1.9G image and install FreeDOS onto it via QEMU. The installer will create and 
format a partition. Then, try to boot it with your 386.

Thinking of this LBA, non-LBA thing we might investigate if it is possible to 
merge the LBA and non-LBA FAT32 VBR code into one. But that is for another 
topic. We also might replace the loaders with some other one. If I remember 
correctly ECMs lDOS loaders have the capability...


As we say, speak the devil's name and here she is!

I prepared an overview of the lDOS FAT32 + FSIBOOT4 loaders on my blog: 
https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0602_barely_any_work_in_the_may_june_week#ldos_fat32_boot_sector_loader_for_freedos


Comments and additional questions are welcome both in this thread or in 
the comment thread of the blog.


Not listed in the article is the lDOS boot.asm (FAT12/FAT16) loader. 
This one also supports the _COMPAT_FREEDOS set but it requires disabling 
some of the loader's features to make the relocation code fit in the 
allowed space. That is why I mention in the article that none of the 
loader's features need to be disabled to use _COMPAT_FREEDOS for my 
boot32.asm as a consequence of the two-stage approach.


As usual, my code is FLOSS and in the case of lDOS boot + instsect + 
lmacros it builds with only NASM (a recent-ish version of the assembler 
may be required).


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[E. C. Masloch via Freedos-devel]

On at 2024-06-02 18:19 +0200, Bernd Böckmann via Freedos-devel wrote:




5. SYS C: /FORCE:CHS


And that boots without problem on the Pocket386!


Also: you asked about FDISK /XO output. It reports "W95B INT LBA
FAT32" in the upper left corner. This is running FDISK 1.3.15.


To Jim: Are you sure you ran FDISK /XO on the Pocket386 system? If FDISK 
says it detects LBA there but the LBA loader from FreeDOS doesn't work 
that'd be quite the bug.



Well, this is good on the one hand, but bad on the other. It means that the 
system (supposedly) supports LBA access, but the FAT32 LBA loader for a reason 
yet unknown to me fails to boot the thing. LBA in general seems to be working. 
Otherwise FDISK would also fail in one way or another.

Have to think about what might be the cause. Looking at the source of FAT32 LBA 
loader, it passes the disk access packet to the BIOS by pushing it onto the 
stack and setting SI=SP, instead of reserving some space for it in its data 
area. Not exactly sure that this is a good idea, as it makes this susceptible 
to stack corruption, depending on how the BIOS mishandles the packet.


The packet on the stack trick is used by some lDOS MBR/boot loaders as 
well, and it generally works.



https://github.com/FDOS/kernel/blob/c0127001908405d30d90f1755ad10c1b59ea8c90/boot/boot32lb.asm#L384

The BIOS may also trash some registers...

Anyone a suggestion?


If it really turns out that FDISK /XO detected LBA support *on the 
Pocket386* but the LBA loader fails, I could cough up some debugging 
hints as to how to install bootable lDebug on the system then debug the 
failing loader. For instance:


1. Rename kernel.sys to fdkernel.sys (exact name doesn't matter)
2. Copy ldebug.com to working drive (using CHS loader) as kernel.sys
3. Boot lDebug
4. Boot FreeDOS using "BOOT PROTOCOL FREEDOS fdkernel.sys" then "Q"
5. Write loader to file: "SYS C: /BOOTONLY /FORCE:LBA BOOTSECT.DOS"
6. Reboot into lDebug
7. Try "BOOT PROTOCOL CHAIN" and then trace the loader

You could install the FAT32+FSIBOOT loader for lDebug as well but when 
you already have a working boot loader then this would just be the 
possible cause of more headaches. Not impossible, but not worth it 
probably. As I have oft repeated lDebug can be loaded as a number of 
kernel formats, most recently including the FreeDOS and the original 
Enhanced DR-DOS (v7.01.07) kernel load formats.


I will advertise the lDOS FAT32 loader more in another subsequent email.

Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Bernd Böckmann via Freedos-devel]

The LBA routine of the FAT16 loader seems to work for Jim. It is taking a more 
"conservative" approach compared to the one in the FAT32 loader, in that it 
reserves some space for the DAP in its data area instead of reserving it on the 
stack.

I agree that including a choice in the installer would be overkill, but the 
loader should nevertheless be altered to support both LBA and non-LBA, without 
multi-sector reads, as there is a higher chance of something going wrong.

Combining the LBA/non-LBA loaders would make it easier to transfer the disk 
images. Not very user friendly to make the user have to change the VBR code, as 
experienced by Jim.


> Am 02.06.2024 um 19:16 schrieb Eric Auer via Freedos-devel 
> :
> 
> 
> Hi!
> 
>>> It would be possible to add an additional screen to the installer
>>> (probably only advanced mode) to use the /FORCE:CHS option.
> 
>> That would be a good option to have, but I'd like to fix sys bootcode  so
>> lba code works and maybe make a multi sector fat32 version that supports
>> both chs & lba...
> 
> If you SYS on the same system where you work later, SYS will
> detect whether or not there is FAT32 support. I think it would
> be overkill to have a multi-sector boot loader which supports
> all options on FAT32. Today, LBA support is widespread enough
> and our FAT12 / FAT16 boot sector already supports CHS and LBA
> in one combined (also somewhat over-engineered) boot sector :-)
> 
> Regards, Eric
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[E. C. Masloch via Freedos-devel]

On at 2024-06-02 19:16 +0200, Eric Auer via Freedos-devel wrote:


Hi!


It would be possible to add an additional screen to the installer
(probably only advanced mode) to use the /FORCE:CHS option.



That would be a good option to have, but I'd like to fix sys bootcode  so
lba code works and maybe make a multi sector fat32 version that supports
both chs & lba...


If you SYS on the same system where you work later, SYS will
detect whether or not there is FAT32 support.


I think you meant "LBA support" in this line. And indeed it does, but 
this doesn't work as intended if the target system doesn't support LBA 
but the installer system does.



I think it would
be overkill to have a multi-sector boot loader which supports
all options on FAT32. Today, LBA support is widespread enough
and our FAT12 / FAT16 boot sector already supports CHS and LBA
in one combined (also somewhat over-engineered) boot sector :-)


I will write more on this in a subsequent mail.

Regards,
ecm




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi!


It would be possible to add an additional screen to the installer
(probably only advanced mode) to use the /FORCE:CHS option.



That would be a good option to have, but I'd like to fix sys bootcode  so
lba code works and maybe make a multi sector fat32 version that supports
both chs & lba...


If you SYS on the same system where you work later, SYS will
detect whether or not there is FAT32 support. I think it would
be overkill to have a multi-sector boot loader which supports
all options on FAT32. Today, LBA support is widespread enough
and our FAT12 / FAT16 boot sector already supports CHS and LBA
in one combined (also somewhat over-engineered) boot sector :-)

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[perditionc--- via Freedos-devel]

On Sun, Jun 2, 2024, 12:25 PM Jerome Shidel via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Glad you got it working Jim.
>
> So, for fixing the issue…
>
> It would be possible to add an additional screen to the installer
> (probably only advanced mode) to use the /FORCE:CHS option.
>
> Most likely, update the existing page to “SYS files with default boot
> record, sys with CHS, don’t xfer sys files”
>
> Or, does the group think there is a better solution?
>
> Jerome
>
>
> .



That would be a good option to have, but I'd like to fix sys bootcode  so
lba code works and maybe make a multi sector fat32 version that supports
both chs & lba.

Jeremy
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jerome Shidel via Freedos-devel]

Glad you got it working Jim.

So, for fixing the issue…

It would be possible to add an additional screen to the installer (probably 
only advanced mode) to use the /FORCE:CHS option. 

Most likely, update the existing page to “SYS files with default boot record, 
sys with CHS, don’t xfer sys files”

Or, does the group think there is a better solution?

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Bernd Böckmann via Freedos-devel]

> 
> 5. SYS C: /FORCE:CHS
> 
> 
> And that boots without problem on the Pocket386!
> 
> 
> Also: you asked about FDISK /XO output. It reports "W95B INT LBA
> FAT32" in the upper left corner. This is running FDISK 1.3.15.
> 

Well, this is good on the one hand, but bad on the other. It means that the 
system (supposedly) supports LBA access, but the FAT32 LBA loader for a reason 
yet unknown to me fails to boot the thing. LBA in general seems to be working. 
Otherwise FDISK would also fail in one way or another.

Have to think about what might be the cause. Looking at the source of FAT32 LBA 
loader, it passes the disk access packet to the BIOS by pushing it onto the 
stack and setting SI=SP, instead of reserving some space for it in its data 
area. Not exactly sure that this is a good idea, as it makes this susceptible 
to stack corruption, depending on how the BIOS mishandles the packet.

https://github.com/FDOS/kernel/blob/c0127001908405d30d90f1755ad10c1b59ea8c90/boot/boot32lb.asm#L384

The BIOS may also trash some registers...

Anyone a suggestion?



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Bernd Böckmann wrote:
> >
[..]
> > You might try doing a "SYS X: /FORCE:CHS" under QEMU and then testing
> > again with your 386 to see if the FAT32 CHS loader works. This is not
> > documented via SYS /? but should work according to the source. You
> > can find out if LBA is supported by starting FDISK via FDISK /XO on
> > the 386. In the top line there will be an indication "LBA" if FDISK
> > (and probably the other FreeDOS parts) make use of it.

That appears to fix it! Here's what I did:

1. connect CF card to Linux (/dev/sda)

2. run QEMU:

sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


3. run FDISK .. delete partitions .. reboot .. create new partition ..
1 single partition .. reboot

4. FORMAT C:

5. SYS C: /FORCE:CHS


And that boots without problem on the Pocket386!

I then continued:


6. connect CF back into Linux (/dev/sda)

7. run QEMU

8. SETUP ADV .. don't transfer system files .. do "plain DOS" install


And now I have a working FreeDOS T2406 installation on the Pocket386!


Also: you asked about FDISK /XO output. It reports "W95B INT LBA
FAT32" in the upper left corner. This is running FDISK 1.3.15.

FDISK /INFO shows this:

> Current fixed disk drive: 1   3632832 sectors, geometry 901/064/63
>
> Partition   Status   Mbytes   System   Usage   Start CHSEnd CHS
>  C: 1  11  A   1775   FAT-32   100%0/001/01  901/063/63


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

On Sun, Jun 2, 2024 at 6:31 AM Bernd Böckmann  wrote:
>
> Hi Jim,
>
> > Am 02.06.2024 um 01:45 schrieb Jim Hall via Freedos-devel 
> > :
> >
>
> > (I created a single partition on the 1.9G drive, formatted and
> > installed "plain DOS" to that, everything works fine)
> >
>
> How did you create the partition? Did you run FDISK or did you re-use
> an existing 1.9G partition shipped with the original image?

To be clear, by "everything works fine," I meant "everything works
fine in QEMU. This step was before writing the image back to the CF
card.

I used FDISK from the FreeDOS T2406 install media. Specifically I
booted T2406 in QEMU .. deleted the partitions .. rebooted T2406 ..
created new partition .. rebooted T2406 .. did the rest of the install
steps as usual.

> > It stops at "Loading FreeDOS" and just hangs there
>
>
> This comes from the (FAT32 LBA?) volume boot code installed by the SYS
> command. There can be several reasons why it fails, the most probable
> being the partition layout. But it may also be that the 386 does not
> support LBA, and SYS puts the LBA-only loader onto the disk while
> running under QEMU. This might make the VBR code stuck in an infinite
> loop, according to the source. Or, there is some incompatibility with
> the BIOS...

It's an AMIBIOS (version 1.16) from 1996. With what I have seen so
far, I agree that the issue is likely to be limitations in the BIOS.
But I'll keep experimenting with different configs to work it out.


> You might try doing a "SYS X: /FORCE:CHS" under QEMU and then testing
> again with your 386 to see if the FAT32 CHS loader works. This is not
> documented via SYS /? but should work according to the source. You
> can find out if LBA is supported by starting FDISK via FDISK /XO on
> the 386. In the top line there will be an indication "LBA" if FDISK
> (and probably the other FreeDOS parts) make use of it.

I'll run that FDISK command in an upcoming test.


> If the 10MB partition can be booted from, we have to take into account
> that this is a FAT16 partition, and accordingly the FAT12/16 volume
> boot code is installed. This supports both LBA and non-LBA access.
>
> Jim, can you upload the non-working image and the working 10MB test
> image, so I can have a look at the relevant data structures (MBR etc.)?
>
> https://nextcloud.iww.rwth-aachen.de/index.php/s/BRXqZDGasw74NN9

I'm uploading two files to you:

10mb.cf is the "install" I did yesterday with a single 10MB partition.
It's not really an "install," though. That's where I just did FDISK
then FORMAT /S ... but at least it booted to a prompt. :-)

newinstall.cf is a test I just did, repeating one of my tests from
yesterday. It also ends up getting stuck at "Loading FreeDOS" and just
hangs.


For both of these images, I installed it using direct access to the CF card:

$ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


And then made the images using dd:

$ sudo dd if=/dev/sda of=newinstall.cf
3637872+0 records in
3637872+0 records out
1862590464 bytes (1.9 GB, 1.7 GiB) copied, 97.3253 s, 19.1 MB/s


> What BIOS is this machine using?

AMIBIOS (version 1.16) from 1996


> As Jerome said, the FreeDOS installer will re-use an existing partition
> layout. So what you can try (not 100% sure you already did that): start
> with an empty 1.9G image and install FreeDOS onto it via QEMU. The
> installer will create and format a partition. Then, try to boot it
> with your 386.


That's what I've done in every case: boot the installer .. run FDISK
to delete partitions .. reboot .. run FDISK to create partition(s) ..
reboot .. do the rest of the install. I didn't want to "inherit"
whatever partition scheme they provided on the system already. I
figured it was good to show everything could be done with FreeDOS
tools. :-)


> Thinking of this LBA, non-LBA thing we might investigate if it is
> possible to merge the LBA and non-LBA FAT32 VBR code into one. But that
> is for another topic. We also might replace the loaders with some other
> one. If I remember correctly ECMs lDOS loaders have the capability...

I think if we're seeing devices like the Book8088 and Pocket386,
that's probably a good suggestion. But as you said, that's probably
best for another thread.



Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Bernd Böckmann via Freedos-devel]

Hi Jim,

> Am 02.06.2024 um 01:45 schrieb Jim Hall via Freedos-devel 
> :
> 

> (I created a single partition on the 1.9G drive, formatted and
> installed "plain DOS" to that, everything works fine)
> 

How did you create the partition? Did you run FDISK or did you re-use an 
existing 1.9G partition shipped with the original image?

> It stops at "Loading FreeDOS" and just hangs there


This comes from the (FAT32 LBA?) volume boot code installed by the SYS command. 
There can be several reasons why it fails, the most probable being the 
partition layout. But it may also be that the 386 does not support LBA, and SYS 
puts the LBA-only loader onto the disk while running under QEMU. This might 
make the VBR code stuck in an infinite loop, according to the source. Or, there 
is some incompatibility with the BIOS...

You might try doing a "SYS X: /FORCE:CHS" under QEMU and then testing again 
with your 386 to see if the FAT32 CHS loader works. This is not documented via 
SYS /? but should work according to the source. You can find out if LBA is 
supported by starting FDISK via FDISK /XO on the 386. In the top line there 
will be an indication "LBA" if FDISK (and probably the other FreeDOS parts) 
make use of it.

If the 10MB partition can be booted from, we have to take into account that 
this is a FAT16 partition, and accordingly the FAT12/16 volume boot code is 
installed. This supports both LBA and non-LBA access.

Jim, can you upload the non-working image and the working 10MB test image, so I 
can have a look at the relevant data structures (MBR etc.)?

https://nextcloud.iww.rwth-aachen.de/index.php/s/BRXqZDGasw74NN9

What BIOS is this machine using?

As Jerome said, the FreeDOS installer will re-use an existing partition layout. 
So what you can try (not 100% sure you already did that): start with an empty 
1.9G image and install FreeDOS onto it via QEMU. The installer will create and 
format a partition. Then, try to boot it with your 386.

Thinking of this LBA, non-LBA thing we might investigate if it is possible to 
merge the LBA and non-LBA FAT32 VBR code into one. But that is for another 
topic. We also might replace the loaders with some other one. If I remember 
correctly ECMs lDOS loaders have the capability...

Bernd






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[tom ehlert via Freedos-devel]

> 5. Boot the Pocket386 from the CF card

> It stops at "Loading FreeDOS" and just hangs there

these symptoms are remarkably similar to " Problem booting FreeDOS on Book8088 
PC-XT laptop"
from earlier this year.

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Eric Auer via Freedos-devel]

Hi Willi,

checking tools like chkdsk which support FAT16 only than dosfsck (the 
only one that supports FAT 32, but even this one stops at 256 gb. The 
actual Linux dosfsck supports 2 tb, it is part of dosfstools).


If you want to know which type of FAT your kernel supports and which
type of FAT a specific DOS drive letter has, you can use WHICHFAT, see:

https://auersoft.eu/soft/specials/

Note that the DOS port of dosfsck does not try to limit supported
disk sizes. All 28 valid bits of FAT32 are supported and the usual
32-bit sector numbering is supported. Maybe you simply did not have
enough RAM to check drives larger than 256 GB? Because dosfsck for
DOS is compiled with DJGPP, be aware that it might be tempted to use
a swap file via CWSDPMI. You may want to disable that by configuring
CWSDPMI in a suitable way, or load another DPMI host like DPMIONE :-)

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On Jun 1, 2024, at 7:56 PM, Jim Hall via Freedos-devel 
>  wrote:
> Jim Hall wrote:
>> My CF card reader arrived, so I tried installing FreeDOS on the CF
>> card. I've had partial success; I can install, but I can't boot. I
>> need help.
> [..]
>> I've also tried running QEMU directly against the CF card, in case
>> something weird happened when I was trying to write the CF card. So I
>> did this:
>> 
>> $ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
>> T2406LIVE.iso -boot order=d
>> 
>> 
>> And that FreeDOS install works fine too. Same as step 3. But it hangs
>> at "Loading FreeDOS" when I boot the Pocket386 with the CF card.
> 
> 
> I just did another test, one I should have tried first:
> 
> 
> 1. Ran QEMU directly against the CF card (same QEMU command line as above)
> 
> 2. Did *not* run the installer
> 
> 3. Manually ran FDISK, delete all partitions
> 
> 4. Reboot .. run FDISK, create a single 10MB partition
> 
> 5. Reboot .. FORMAT C: /s
> 
> 
> And then I put the CF card back into the Pocket386, and it boots!
> There's nothing there (I didn't install, just made a tiny partition
> bootable) but at least it works!!
> 
> So I'll do more work with this tomorrow and put FreeDOS on it, even if
> I have to do everything without the installer.
> 
> 
> (I don't think the installer is specifically at fault, probably something 
> else.)
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

To me, it sounds like the 386 would not boot the CF, but QEMU would boot the 
image of the CF…

Based on your messages, since the CF did not boot in the 386 at all and boots 
the image of the CF fine in QEMU, it has to be one of only a couple things. 

Let’s not forget, the installer uses the same tools to perform its installation 
that you would or can use. Also, the problem happens immediately on boot. So, 
it is not going to be a package installation issue but a very low level problem.

First depending on the exact steps taken for the original install, it is 
possible that the original MBR was left intact. It would be weird (but not 
impossible) for that MBR to boot windows but not FreeDOS only on the 386. While 
QEMU could boot either. But, I would not suspect this was the issue.

Next, it is possible that the 386 did not like the parameters of the partition 
or its size in the first attempt. 

Third, there a difference when it comes to the formatting and transfer of 
system files. Your post said you did a simple “format /s”. The installer does a 
“format /q” without transferring the system files. Later on it uses the “sys” 
command to transfer the system files.

Like with the MBR, I think the end result would either work on both or neither.

So, this is what I would do…

Create and format the partition of the size you want on the image file. Copy 
the floppy installer directory from the CD to the imaged drive. (Be sure to put 
it in a subdirectory). 

Write the image back to the CF and verify it boots.

The change to the subdirectory with the floppy installer and run that. Since 
the drive is already formatted and partitioned, it will skip those steps.

Unlike the main installer used by the USB sticks and CD media, the floppy 
installer will run from a subdirectory and permit installation to the same 
drive. 

Jerome





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Jim Hall wrote:
> My CF card reader arrived, so I tried installing FreeDOS on the CF
> card. I've had partial success; I can install, but I can't boot. I
> need help.
>
[..]
> I've also tried running QEMU directly against the CF card, in case
> something weird happened when I was trying to write the CF card. So I
> did this:
>
> $ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
> T2406LIVE.iso -boot order=d
>
>
> And that FreeDOS install works fine too. Same as step 3. But it hangs
> at "Loading FreeDOS" when I boot the Pocket386 with the CF card.


I just did another test, one I should have tried first:


1. Ran QEMU directly against the CF card (same QEMU command line as above)

2. Did *not* run the installer

3. Manually ran FDISK, delete all partitions

4. Reboot .. run FDISK, create a single 10MB partition

5. Reboot .. FORMAT C: /s


And then I put the CF card back into the Pocket386, and it boots!
There's nothing there (I didn't install, just made a tiny partition
bootable) but at least it works!!

So I'll do more work with this tomorrow and put FreeDOS on it, even if
I have to do everything without the installer.


(I don't think the installer is specifically at fault, probably something else.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

> Jim Hall wrote:
> [..]
> > > It arrived Friday. I powered it on to make sure it works, and it does.
> > > They've pre-installed some pirated copy of Win95 on there, but I'll
> > > reinstall the whole thing with FreeDOS anyway. :-)
> > >
> > > The Pocket386 only boots from the internal C: drive (a CF card). I
> > > thought I still had a CF card reader (can't find it) so I've ordered a
> > > new one. My plan is to image the CF card from Linux and make a copy,
> > > then use QEMU with that drive image to install FreeDOS, then write the
> > > image to the CF so I can boot the Pocket386 with it.


My CF card reader arrived, so I tried installing FreeDOS on the CF
card. I've had partial success; I can install, but I can't boot. I
need help.


What I've done:

1. Backup the CF card from Linux:

$ sudo dd if=/dev/sda of=diskimage.cf

2. Make a copy of the CF card image:

$ cp diskimage.cf freedos.cf

3. Install FreeDOS using the CF copy:

$ qemu-system-i386 -enable-kvm -m 32 -hda freedos.cf -cdrom
T2406LIVE.iso -boot order=d

(I created a single partition on the 1.9G drive, formatted and
installed "plain DOS" to that, everything works fine)

4. Write the image back to the CF card:

$ sudo dd if=freedos.sf of=/dev/sda

(I get the same amount written as was read in step 1)

5. Boot the Pocket386 from the CF card

It stops at "Loading FreeDOS" and just hangs there



As a debugging step, I used 'dd' again to write the original image
back to the CF card. Put the CF card back into the Pocket386, and that
boots Win95 as usual:

$ sudo dd if=diskimage.cf of=/dev/sda



I've also tried running QEMU directly against the CF card, in case
something weird happened when I was trying to write the CF card. So I
did this:

$ sudo qemu-system-i386 -enable-kvm -m 32 -hda /dev/sda -cdrom
T2406LIVE.iso -boot order=d


And that FreeDOS install works fine too. Same as step 3. But it hangs
at "Loading FreeDOS" when I boot the Pocket386 with the CF card.



And to confirm: I installed T2406 on QEMU, on my usual virtual disk
setup that I have, and that installed fine. Doesn't hang at boot.


Does anyone have any suggestions?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2406

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2406 for June is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes in T2406:

2024-05-30 14:51:01 runtime (Shidel): Merge branch 'unstable' into 'master'
2024-05-30 10:42:34 upx (shidel): updated 4.2.4
2024-05-30 10:35:09 edlin (shidel): updated to 2.24
2024-05-29 19:15:02 i16env (Shidel): Initial commit
2024-05-29 16:32:15 runtime (shidel): updated to 2024-05-09 version
2024-05-29 15:56:31 project_FDI [unstable] (shidel): added i16env to BonusCD
2024-05-29 15:34:24 i16env (shidel): adjusted package config
2024-05-29 15:31:26 i16env (shidel): initial commit
2024-05-29 09:42:54 project_FDI [unstable] (shidel): correct DOSLFN.CON typo
2024-05-26 19:26:56 fdisk [unstable] (Bernd Boeckmann): release 1.3.15
2024-05-23 17:37:32 zoo (Bernd Wilhelm Böckmann): fix for cluster size >32k
2024-05-07 21:12:50 runtime (shidel): switched to E.Auer version 2024-05-05
2024-05-07 20:44:20 runtime (shidel): latest version from J.Hall
2024-05-07 20:15:58 fdimples (shidel): updated to v0.11.7


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] [FreeDOS-Devel] FOSS Game crobots

[Richard Stoltenberg via Freedos-devel]

https://tpoindex.github.io/crobots/

crobots is now FOSS opensource robot learning game for kids:
gplv2
https://tpoindex.github.io/crobots/

from site:
Documentation

The original manual for CROBOTS is in docs/crobots_manual.html
.
History

CROBOTS was my first adventure into the world of compilers and virtual
machines, and not all that long after I learned C.

In early 1985, I found Jeff Lee's posting of a Yacc grammar for ANSI C, on
the USENET group net.sources
.
Taking Jeff's advice in his post *"(Y)ou can sit and crank your own output
through it to amuse yourself if you have the personality of a cumquat(sp?)"*,
I played with Yacc/Lex and the C grammar to the point of moderately
understanding how it all worked.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

Jim Hall wrote:
[..]
> > It arrived Friday. I powered it on to make sure it works, and it does.
> > They've pre-installed some pirated copy of Win95 on there, but I'll
> > reinstall the whole thing with FreeDOS anyway. :-)
> >
> > The Pocket386 only boots from the internal C: drive (a CF card). I
> > thought I still had a CF card reader (can't find it) so I've ordered a
> > new one. My plan is to image the CF card from Linux and make a copy,
> > then use QEMU with that drive image to install FreeDOS, then write the
> > image to the CF so I can boot the Pocket386 with it.
> >
> > I also ordered a PS/2 keyboard, because the built-in keyboard is too
> > tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).


Jerome Shidel wrote:
> Having fun with your 386?
>
> Does it have sound and does it work under DOS?
>
> Where are you Benchmarks??


I haven't tinkered with it too much yet, because that micro keyboard
makes my wrists ache just by *looking* at it. The keys are so tiny
(letters are 13mm x 11mm .. arrows and punctuation keys are 10mm x
11mm) that I often hit the key next to the letter I'm trying to type.
I'm looking forward to using a full-size PS/2 keyboard. :-)

Win95 says:

Cirrus Logic CL-GD 5420 r1 Rev 0 video card (512k video memory)
8 MB RAM
Ad Lib Gold compatible OPL3 sound card

The CPU is 386SX-40.


Since I can't install DOS applications yet (that's why I ordered a CF
card reader) I can't say if the Ad Lib sound card actually works with
DOS games. I'll share an update when the CF card reader arrives and I
wipe this with FreeDOS and put some games and other software on it.
:-)


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jerome Shidel via Freedos-devel]

Hi Jim,

> On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel 
>  wrote:
> 
> *I'm resending (with a few edits/updates) because this message failed
> over the weekend due to the SF list server outage
> 
> 
> You may remember the Book8088 micro-laptop and Hand386 handheld from
> last year. I always said I'd buy one if they were the other way
> around: a handheld 8088 or a '386 laptop.
> 
> Well, then they started selling the Pocket386 - and I bought one.
> 
> It arrived Friday. I powered it on to make sure it works, and it does.
> They've pre-installed some pirated copy of Win95 on there, but I'll
> reinstall the whole thing with FreeDOS anyway. :-)
> 
> The Pocket386 only boots from the internal C: drive (a CF card). I
> thought I still had a CF card reader (can't find it) so I've ordered a
> new one. My plan is to image the CF card from Linux and make a copy,
> then use QEMU with that drive image to install FreeDOS, then write the
> image to the CF so I can boot the Pocket386 with it.
> 
> I also ordered a PS/2 keyboard, because the built-in keyboard is too
> tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).

Having fun with your 386?

Does it have sound and does it work under DOS?

Where are you Benchmarks??

:-)



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Louis Santillan via Freedos-devel]

Instead of investing in PS2, I’m building one or more of these.

https://docs.pikvm.org/pico_hid_bridge/


On Wed, May 29, 2024 at 12:15 AM Jerome Shidel via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
> > On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
> > [..]
> > I also ordered a PS/2 keyboard, because the built-in keyboard is too
> > tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).
>
> I just got one a few weeks ago along with a PS/2 mouse. Both brand new. I
> was kind of surprised they are still being manufactured. Maybe I should
> stock up.
>
> :-)
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Pocket386

[Jerome Shidel via Freedos-devel]

> On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel 
>  wrote:
> [..]
> I also ordered a PS/2 keyboard, because the built-in keyboard is too
> tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).

I just got one a few weeks ago along with a PS/2 mouse. Both brand new. I was 
kind of surprised they are still being manufactured. Maybe I should stock up.

:-)

 

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS on Pocket386

[Jim Hall via Freedos-devel]

*I'm resending (with a few edits/updates) because this message failed
over the weekend due to the SF list server outage


You may remember the Book8088 micro-laptop and Hand386 handheld from
last year. I always said I'd buy one if they were the other way
around: a handheld 8088 or a '386 laptop.

Well, then they started selling the Pocket386 - and I bought one.

It arrived Friday. I powered it on to make sure it works, and it does.
They've pre-installed some pirated copy of Win95 on there, but I'll
reinstall the whole thing with FreeDOS anyway. :-)

The Pocket386 only boots from the internal C: drive (a CF card). I
thought I still had a CF card reader (can't find it) so I've ordered a
new one. My plan is to image the CF card from Linux and make a copy,
then use QEMU with that drive image to install FreeDOS, then write the
image to the CF so I can boot the Pocket386 with it.

I also ordered a PS/2 keyboard, because the built-in keyboard is too
tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

[Jim Hall via Freedos-devel]

Jim wrote:
[..]
> > FYI: I've fixed the source files on my end and mirrored that version
> > to Ibiblio. It's at:
> >
> > https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.24/
> >
> >
> > I've also uploaded a compiled version of EDLIN16.EXE (compiled using OW.BAT)

Gregory wrote:
>
> Okay. Fixed. -- Gregory
>


Awesome, thanks! I've re-mirrored this edlin 2.24 to Ibiblio.

I'll also make a news item on the website for it!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

[Gregory Pietsch via Freedos-devel]

Okay. Fixed. -- Gregory

> On 05/16/2024 3:02 PM EDT Jim Hall via Freedos-devel 
>  wrote:
> 
>  
> On Thu, May 16, 2024 at 1:49 PM Jim Hall  wrote:
> >
> > On Thu, May 16, 2024 at 1:36 PM Gregory Pietsch via Freedos-devel
> >  wrote:
> > >
> > > FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall
> > > sent me some edits that moved the copyright to the help screen and
> > > changed "Abort edit" to "Really quit". It's available on SourceForge
> > > and Jim should mirror it very soon now!
> > >
> >
> >
> > Thanks! Unfortunately, this still advertises itself as 2.23. Can you
> > fix it on SF and I can re-mirror that?
> >[..]
> 
> FYI: I've fixed the source files on my end and mirrored that version
> to Ibiblio. It's at:
> 
> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.24/
> 
> 
> I've also uploaded a compiled version of EDLIN16.EXE (compiled using OW.BAT)
> 
> 
> Jim
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

[Jim Hall via Freedos-devel]

On Thu, May 16, 2024 at 1:36 PM Gregory Pietsch via Freedos-devel
 wrote:
>
> FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall
> sent me some edits that moved the copyright to the help screen and
> changed "Abort edit" to "Really quit". It's available on SourceForge
> and Jim should mirror it very soon now!
>


Thanks! Unfortunately, this still advertises itself as 2.23. Can you
fix it on SF and I can re-mirror that?

D:\SRC\EDLIN224>find "2.23" config*.*
 CONFIG-H.BC
#define PACKAGE_STRING "edlin 2.23"
#define PACKAGE_VERSION "2.23"
#define VERSION "2.23"
 CONFIG-H.OW
#define PACKAGE_STRING "edlin 2.23"
#define PACKAGE_VERSION "2.23"
#define VERSION "2.23"
 CONFIG.GUE
 CONFIG_H.IN
 CONFIG.SUB
 CONFIGUR
 CONFIGUR.AC


Might want to update ow.bat too:

D:\SRC\EDLIN224>find "2.23" *.bat
 OW.BAT
REM builds FreeDOS's edlin 2.23 (by Gregory Pietsch:  gpiet...@comcast.net)
if not exist edlin-2.23\nul if exist edlin-2.23.zip unzip edlin-2.23.zip
if not exist edlin-2.23\nul goto end
cd edlin-2.23


I should have sent complete changes that updated the version to 2.24
for you, too. Sorry about that.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Edlin 2.24 is out!

[Jim Hall via Freedos-devel]

On Thu, May 16, 2024 at 1:49 PM Jim Hall  wrote:
>
> On Thu, May 16, 2024 at 1:36 PM Gregory Pietsch via Freedos-devel
>  wrote:
> >
> > FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall
> > sent me some edits that moved the copyright to the help screen and
> > changed "Abort edit" to "Really quit". It's available on SourceForge
> > and Jim should mirror it very soon now!
> >
>
>
> Thanks! Unfortunately, this still advertises itself as 2.23. Can you
> fix it on SF and I can re-mirror that?
>[..]

FYI: I've fixed the source files on my end and mirrored that version
to Ibiblio. It's at:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/edlin/2.24/


I've also uploaded a compiled version of EDLIN16.EXE (compiled using OW.BAT)


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Edlin 2.24 is out!

[Gregory Pietsch via Freedos-devel]

FreeDOS Edlin 2.24 has been released to an unsuspecting world! Jim Hall sent me 
some edits that moved the copyright to the help screen and changed "Abort edit" 
to "Really quit". It's available on SourceForge and Jim should mirror it very 
soon now!
 
Gregory___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Terminal

[Wilhelm Spiegl via Freedos-devel]

+1 for terminal and runtime.

 

Hi Jim, hi all,

I fear to embarrass myself, but I have this account for in about 15 years now - and forgotten the access data. My problem is that I am not very trained in this mailing lists,

and I do not like them, because hundreds of people notice it if I tell an absolutely bullshit - or I send a mail to everyone that is not thought

for everyone - or send a response via an absolutely different theme. All this already happened to me several times.

My main problem is, that I can answer via mail, but I have absolutely forgotten how to create a new thread. (now a lot of users will laugh...)

Simply changing the "Subject" seems not to be the solution. This are some of the reasons why I prefer sending mails directly.

And sourceforge site itself does not make it simpler.

I created a new account fritz_mueller - but then I was lost in sourceforge jungle. There is a long long list of old threads - but I found no position

where to start a new one.

Maybe someone can help me.

Sorry that I have to say this. My feeling is, that "https://freedos.org/forums/"  - Ask a question - For developers - subscribe only leads to this jungle.

 

PS: I have the feeling that I will have to repeat the issues that I have reported at GitLab at the mailing list as soon as I am able to create

new threads here. This will be a longer list.

 

Willi

 

 
 

Sent: Friday, May 03, 2024 at 1:42 AM
From: "Jim Hall via Freedos-devel" 
To: "Technical discussion and questions for FreeDOS developers." 
Cc: "Jim Hall" 
Subject: Re: [Freedos-devel] FreeDOS Terminal

Good "netiquette" is to only discuss one topic per email thread, so I
started a new thread for Terminal:


On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
 wrote:
> Willi has asked Jerome and me whether RUNTIME and TERMINAL
> in the auersoft.eu versions were real updates or just tests.
>
> Jerome asked him to ask on the LIST, so I answer HERE ;-)
[..]

Yes, and please avoid sending off-list emails. We have the email list
so we can talk about things in the open.


> *Terminal*
>
> Regarding TERMINAL, the distro contains version 3.2a 2015-05-16.
> The files in the ZIP have timestamps between 2001 and 2005 for
> source code and 2021-2022 for translations.
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/terminal.html
>
> The version mentioned by Willi, terminal-2007jun20, contains
> 2007 changes to terminal.asm, term-irq.asm and term-data.asm,
> with the following minimalist changelog:
>
> "update in V3.3 6/2007: added a forgotten in al,dx term-irq.asm:217"
>
> The change in terminal.asm are just adding the above as a comment.
> The change in term-irq.asm is just adding that "in al,dx".
> The change in term-data.asm is just changing version and date in
> the msg_hello string. Note that the sources have LONG FILE NAMES
> which somehow got lost in the download available on Ibiblio!
>
> The version on ibiblio comes with more metadata in APPINFO: The
> LSM file and small TERMINAL.xyz files in different languages xyz,
> for example the French APPINFO/TERMINAL.FR file says:
>
> Begin3
> Language: FR, 850
> Title: terminal
> Description: Un petit terminal vt100/ansi pour tous les PC
> Keywords: terminal, rs-232, vt100
> End
>
> I guess it would be nice if the ibiblio version got updated with
> my 2007 version, but preserving the nice added ibiblio metadata.
> Please take care to preserve source LFN and timestamps, though.


I see the 2007 Terminal in the Ibiblio archive, so it looks like we
made a copy at some point. It is here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/terminal/


The 2007 version has these file dates/times:

$ ls -l
total 224
-rw-r- 1 freedos users 6014 Nov 16 2001 README
-rw-r--r-- 1 freedos users 46662 Nov 18 2001 terminal-2001nov18.zip
-rw-r--r-- 1 freedos users 48049 Nov 6 2002 terminal-2002nov06.zip
-rw-r--r-- 1 freedos users 44538 Apr 23 2005 terminal-2005apr23.zip
-rw-r--r-- 1 freedos users 44520 Jun 20 2007 terminal-2007jun20.zip
-rw-r--r-- 1 freedos users 13608 Apr 23 2005 terminal-rom.tar.gz


And:

$ unzip -l terminal-2007jun20.zip
Archive: terminal-2007jun20.zip
Length Date Time Name
- -- - 
0 06-20-2007 11:17 terminal/
4175 10-20-2001 01:37 terminal/term-comm.asm
6613 06-20-2007 11:17 terminal/term-data.asm
1823 10-18-2001 14:55 terminal/term-def.asm
635 10-19-2001 17:39 terminal/eecho.asm
6333 04-23-2005 14:16 terminal/term-tty.asm
3867 06-20-2007 11:17 terminal/terminal.com
123 10-19-2001 17:40 terminal/eecho.com
11944 06-20-2007 11:17 terminal/terminal.asm
197 11-16-2001 13:05 terminal/prn-term.inf
7962 06-20-2007 11:16 terminal/term-irq.asm
2516 11-16-2001 11:27 terminal/term-menu.asm
17061 10-20-2001 15:15 terminal/term-ansi.asm
8

Re: [Freedos-devel] FreeDOS Runtime

[Vacek Nules via Freedos-devel]

Hello Jim,

I am a native Hungarian speaker (despite bearing a first name of Slavic
origin).
If you need help in translating anything to Hungarian, just tell me, I'll
gladly help

Regards,
Vacek


Jim Hall via Freedos-devel  ezt írta
(időpont: 2024. máj. 3., Pén 2:05):

> Good "netiquette" is to only discuss one topic per email thread, so I
> started a new thread for Runtime:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
>  wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?
> >
> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-) To add languages,
> > you have to build a new binary. Not very hard, but harder
> > than just editing a text file which can be used by CATGETS.
> > The binary is a 2kB COM (3kB without UPX).
> >
> > Note that texts in all 10 language are INCLUDED in the 2kB
> > COM file of my tiny version. No separate NLS files there.
> >
> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.
> >
> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)
> >
>
>
> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements. There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around - but decided it would be just as easy to write my own for
> what I needed to do. It was just a quick program that I probably wrote
> in ten minutes.
>
> And I probably released it in case it was useful to someone else. I
> don't think I intended it to become part of the distribution, but it
> did.
>
> I just looked at the zip file for Runtime 1.0. It's a very simple
> program, just sets a timer, runs a program, then reports how long the
> program ran.
>
>
> That's the long version to say: I don't have a particularly strong
> opinion to keep the old Runtime in the distribution. We can swap it
> out.
>
> I looked at your Runtime, and the messages are very simple:
>
>
> 1. seconds [as in, 'this ran in 4 seconds]
>
> 2. passed [as in, '4 seconds have passed']
>
> 3. a 1-line "about" message
>
> 4. a 1-line "usage" message
>
> 5. a 1-line "information" message
>
> 6. a "COMSPEC not found" error message
>
>
> So it's just 6 messages, which seems right. It's not a very complicated
> program.
>
>
> I'm in favor to swap out the old Runtime with this Runtime. No issues
> here. I think it would be great to have those 6 messages translated
> into the missing HU and LV translations, but I don't think we need to
> "wait" for those messages to get translated.
>
> What do others think? You can "+1" if you just want to agree to swap
> out my old Runtime with Eric's newer Runtime.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Runtime

[Jim Hall via Freedos-devel]

Good "netiquette" is to only discuss one topic per email thread, so I
started a new thread for Runtime:

On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
 wrote:
[..]
> *Runtime*
>
> Jim's version is a small C program, 120 lines, using catgets
> for messages which can be translated in different languages.
> The binary is a 22kB EXE (31kB without UPX). There were text
> files with EN, RU, DE, HU and LV translations, I believe?
>
> My version is a small ASM program, made with NASM. It has
> a main file, circa 450 lines, and a language include file,
> circa 150 lines, which at the moment contains EN, DE, NL,
> PT, ES, FR, TR, IT, PL and RU messages :-) To add languages,
> you have to build a new binary. Not very hard, but harder
> than just editing a text file which can be used by CATGETS.
> The binary is a 2kB COM (3kB without UPX).
>
> Note that texts in all 10 language are INCLUDED in the 2kB
> COM file of my tiny version. No separate NLS files there.
>
> As a task left as an exercise for the user, one could port
> the C version to Tom's small KITTEN alternative to CATGETS.
>
> My preferred option would be to add HU and LV translations
> to my small RUNTIME and use that instead of the big one ;-)
>


I wrote the Runtime program, so I guess I'll speak to that.

This is a very old program. I don't remember why I wrote it, but I'm
sure I was doing some debugging on a program and was trying to
fine-tune the performance, and needed a way to test how long it took
to run after making improvements. There are lots of programs out there
to track the run-time of a program on DOS, and I probably gave a quick
look around - but decided it would be just as easy to write my own for
what I needed to do. It was just a quick program that I probably wrote
in ten minutes.

And I probably released it in case it was useful to someone else. I
don't think I intended it to become part of the distribution, but it
did.

I just looked at the zip file for Runtime 1.0. It's a very simple
program, just sets a timer, runs a program, then reports how long the
program ran.


That's the long version to say: I don't have a particularly strong
opinion to keep the old Runtime in the distribution. We can swap it
out.

I looked at your Runtime, and the messages are very simple:


1. seconds [as in, 'this ran in 4 seconds]

2. passed [as in, '4 seconds have passed']

3. a 1-line "about" message

4. a 1-line "usage" message

5. a 1-line "information" message

6. a "COMSPEC not found" error message


So it's just 6 messages, which seems right. It's not a very complicated program.


I'm in favor to swap out the old Runtime with this Runtime. No issues
here. I think it would be great to have those 6 messages translated
into the missing HU and LV translations, but I don't think we need to
"wait" for those messages to get translated.

What do others think? You can "+1" if you just want to agree to swap
out my old Runtime with Eric's newer Runtime.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Terminal

[Jim Hall via Freedos-devel]

Good "netiquette" is to only discuss one topic per email thread, so I
started a new thread for Terminal:


On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
 wrote:
> Willi has asked Jerome and me whether RUNTIME and TERMINAL
> in the auersoft.eu versions were real updates or just tests.
>
> Jerome asked him to ask on the LIST, so I answer HERE ;-)
[..]

Yes, and please avoid sending off-list emails. We have the email list
so we can talk about things in the open.


> *Terminal*
>
> Regarding TERMINAL, the distro contains version 3.2a 2015-05-16.
> The files in the ZIP have timestamps between 2001 and 2005 for
> source code and 2021-2022 for translations.
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/terminal.html
>
> The version mentioned by Willi, terminal-2007jun20, contains
> 2007 changes to terminal.asm, term-irq.asm and term-data.asm,
> with the following minimalist changelog:
>
> "update in V3.3 6/2007: added a forgotten in al,dx term-irq.asm:217"
>
> The change in terminal.asm are just adding the above as a comment.
> The change in term-irq.asm is just adding that "in al,dx".
> The change in term-data.asm is just changing version and date in
> the msg_hello string. Note that the sources have LONG FILE NAMES
> which somehow got lost in the download available on Ibiblio!
>
> The version on ibiblio comes with more metadata in APPINFO: The
> LSM file and small TERMINAL.xyz files in different languages xyz,
> for example the French APPINFO/TERMINAL.FR file says:
>
> Begin3
> Language:FR, 850
> Title:   terminal
> Description: Un petit terminal vt100/ansi pour tous les PC
> Keywords:terminal, rs-232, vt100
> End
>
> I guess it would be nice if the ibiblio version got updated with
> my 2007 version, but preserving the nice added ibiblio metadata.
> Please take care to preserve source LFN and timestamps, though.


I see the 2007 Terminal in the Ibiblio archive, so it looks like we
made a copy at some point. It is here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/terminal/


The 2007 version has these file dates/times:

$ ls -l
total 224
-rw-r- 1 freedos users  6014 Nov 16  2001 README
-rw-r--r-- 1 freedos users 46662 Nov 18  2001 terminal-2001nov18.zip
-rw-r--r-- 1 freedos users 48049 Nov  6  2002 terminal-2002nov06.zip
-rw-r--r-- 1 freedos users 44538 Apr 23  2005 terminal-2005apr23.zip
-rw-r--r-- 1 freedos users 44520 Jun 20  2007 terminal-2007jun20.zip
-rw-r--r-- 1 freedos users 13608 Apr 23  2005 terminal-rom.tar.gz


And:

$ unzip -l terminal-2007jun20.zip
Archive:  terminal-2007jun20.zip
  Length  DateTimeName
-  -- -   
0  06-20-2007 11:17   terminal/
 4175  10-20-2001 01:37   terminal/term-comm.asm
 6613  06-20-2007 11:17   terminal/term-data.asm
 1823  10-18-2001 14:55   terminal/term-def.asm
  635  10-19-2001 17:39   terminal/eecho.asm
 6333  04-23-2005 14:16   terminal/term-tty.asm
 3867  06-20-2007 11:17   terminal/terminal.com
  123  10-19-2001 17:40   terminal/eecho.com
11944  06-20-2007 11:17   terminal/terminal.asm
  197  11-16-2001 13:05   terminal/prn-term.inf
 7962  06-20-2007 11:16   terminal/term-irq.asm
 2516  11-16-2001 11:27   terminal/term-menu.asm
17061  10-20-2001 15:15   terminal/term-ansi.asm
 8359  10-19-2001 15:32   terminal/term-disp.asm
 3175  04-23-2005 14:14   terminal/term-set.asm
 6014  11-16-2001 13:04   terminal/terminal.txt
18349  03-01-2002 08:29   terminal/copying.txt
 3975  11-06-2002 14:04   terminal/term.bat
- ---
   103121 18 files


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] freedos runtime and terminal updates and alternatives

[Eric Auer via Freedos-devel]

Hi!

Willi has asked Jerome and me whether RUNTIME and TERMINAL
in the auersoft.eu versions were real updates or just tests.

Jerome asked him to ask on the LIST, so I answer HERE ;-)

*Runtime*

Jim's version is a small C program, 120 lines, using catgets
for messages which can be translated in different languages.
The binary is a 22kB EXE (31kB without UPX). There were text
files with EN, RU, DE, HU and LV translations, I believe?

My version is a small ASM program, made with NASM. It has
a main file, circa 450 lines, and a language include file,
circa 150 lines, which at the moment contains EN, DE, NL,
PT, ES, FR, TR, IT, PL and RU messages :-) To add languages,
you have to build a new binary. Not very hard, but harder
than just editing a text file which can be used by CATGETS.
The binary is a 2kB COM (3kB without UPX).

Note that texts in all 10 language are INCLUDED in the 2kB
COM file of my tiny version. No separate NLS files there.

As a task left as an exercise for the user, one could port
the C version to Tom's small KITTEN alternative to CATGETS.

My preferred option would be to add HU and LV translations
to my small RUNTIME and use that instead of the big one ;-)

*Terminal*

Regarding TERMINAL, the distro contains version 3.2a 2015-05-16.
The files in the ZIP have timestamps between 2001 and 2005 for
source code and 2021-2022 for translations.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/terminal.html

The version mentioned by Willi, terminal-2007jun20, contains
2007 changes to terminal.asm, term-irq.asm and term-data.asm,
with the following minimalist changelog:

"update in V3.3 6/2007: added a forgotten in al,dx term-irq.asm:217"

The change in terminal.asm are just adding the above as a comment.
The change in term-irq.asm is just adding that "in al,dx".
The change in term-data.asm is just changing version and date in
the msg_hello string. Note that the sources have LONG FILE NAMES
which somehow got lost in the download available on Ibiblio!

The version on ibiblio comes with more metadata in APPINFO: The
LSM file and small TERMINAL.xyz files in different languages xyz,
for example the French APPINFO/TERMINAL.FR file says:

Begin3
Language:FR, 850
Title:   terminal
Description: Un petit terminal vt100/ansi pour tous les PC
Keywords:terminal, rs-232, vt100
End

I guess it would be nice if the ibiblio version got updated with
my 2007 version, but preserving the nice added ibiblio metadata.
Please take care to preserve source LFN and timestamps, though.

Thank you :-)

Cheers, Eric



[...]

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/runtime/
 there is a version from Eric Auer from 03sep2012
 FDT2404 uses ver. 2.1 from Jim Hall, 2002
Is it an update? You should bring it up on the mailing list or ask Eric if it 
should be updated.

terminal https://www.auersoft.eu/soft/  terminal-2007jun20 (3.3)
  FDT2404 uses 3.2a
Like RUNTIME, these versions predate me performing package updates. So, I don't 
know
if those are updates, experiments or just different. You should ask Eric.

[...]




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2405

[Jerome Shidel via Freedos-devel]

Hi Willi,On May 1, 2024, at 10:20 AM, Wilhelm Spiegl via Freedos-devel  wrote:Hi Jerome, thanks for this statement.

 

I know that you are very very busy, and it is not really urgent, but it would be nice to keep it in mind.

 

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/apps/ - and there: doszip.zip

or:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel - and there dojs.zip

 

are not up to date, which leads to the result that it is not possible to download the latest versions via fdnpkg update.

 

Willi
They’ll be updated either later today or tomorrow at those location.I wasn’t able to make time to update the packages for T2405 until last night. Basically what happens is this…I update the packages at the GitLab FreeDOS archive.  Which performs a bunch of validation and such things. It also wraps them up into a package. This is where the RBE (release build environment) fetch’s the packages for the Interim and Release builds.Then I download the FreeDOS compatible package from GitLab.Then I upload them to my server at http://fd.lod.bz and the repository management tools make some adjustments to the metadata. My server checks for such updates hourly.Then I download that from my server and upload it ibiblio. The repo management tools also are running there. However, they will see the adjustments to the metadata have already been made and just update its web pages. Ibiblio only checks automatically once per day for updates.Unfortunately, the underlying utilities that get used to update the metadata can very slightly between the 2 servers. That can result in different hashes for the packages. Since the repo management software on both servers is the same. The order of upload to those servers is not important. It’s just easier to update ibiblio last. Especially since there can be multiple copies of the packages in the different OS version repositories on that server.Anyhow, those are already on GitLab and my server. Just waiting for me to download them and upload copies to ibiblio. I will be away from a computer for most of the day today. (Sending this from a phone). But, I should get to that at some point before tomorrow.:-)Jerome 

Sent: Wednesday, May 01, 2024 at 12:12 PM
From: "Jerome Shidel via Freedos-devel" 
To: "FreeDOS Developers" 
Cc: jer...@shidel.net
Subject: [Freedos-devel] FreeDOS Interim Build T2405



The FreeDOS Interim Test Build T2405 for May is now available for download at:

 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/

 

A special thanks to Wilhelm for pointing out most of the updates and providing links for me to download.

 

I’ve been very time constrained of late. Without his support, the only updated program in this Build would have been NASM. He also provided information and links regarding several other items. However, I should follow up on that in a different post. 

 

Thanks again Willi for the time and effort you put into searching for updates. It is a big help. :-)

 

 

Overview of changes in this Interim Build:

 


2024-04-30 21:54:27 suppls (shidel): relocated developer files from source to devel

2024-04-30 21:39:55 dojs (shidel): updated to v1.12.1 (The puny port)

2024-04-30 21:36:21 doszip (shidel): updated to v2.66

2024-04-30 21:32:30 testdisk (shidel): updated to v7.2 (final)

2024-04-30 21:27:47 fasm (shidel): updated to v1.73.32

2024-04-30 21:22:13 nasm (shidel): updated to v2.16.03

2024-04-13 07:11:10 nasm (shidel): updated to version 2.16.02

2024-04-04 20:33:02 project_FD-NLS (cardpuncher): Add files via upload

2024-04-04 16:14:11 project_FD-NLS (shidel): report update

2024-04-04 15:19:11 project_FD-NLS (shidel): Merge pull request #191 from cardpuncher/master

2024-04-03 20:02:23 project_FD-NLS (shidel): report update

2024-04-03 19:18:04 project_FD-NLS (shidel): Merge branch 'master' of github.com:shidel/fd-nls

2024-04-03 18:46:51 project_FD-NLS (shidel): FDNET DOSBox Staging Strings

2024-04-03 15:03:49 project_FD-NLS (shidel): Merge pull request #190 from cardpuncher/master

2024-04-03 15:02:20 fdnet [unstable] (shidel): DOSBox Staging networking support

2024-04-03 14:40:43 project_FDI [unstable] (shidel): DOSBox Hybrid install, FDAUTO path typo fix


 

Jerome
___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel





___Freedos-devel mailing listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2405

[Wilhelm Spiegl via Freedos-devel]

Hi Jerome, thanks for this statement.

 

I know that you are very very busy, and it is not really urgent, but it would be nice to keep it in mind.

 

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/apps/ - and there: doszip.zip

or:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel - and there dojs.zip

 

are not up to date, which leads to the result that it is not possible to download the latest versions via fdnpkg update.

 

Willi
 

Sent: Wednesday, May 01, 2024 at 12:12 PM
From: "Jerome Shidel via Freedos-devel" 
To: "FreeDOS Developers" 
Cc: jer...@shidel.net
Subject: [Freedos-devel] FreeDOS Interim Build T2405



The FreeDOS Interim Test Build T2405 for May is now available for download at:

 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/

 

A special thanks to Wilhelm for pointing out most of the updates and providing links for me to download.

 

I’ve been very time constrained of late. Without his support, the only updated program in this Build would have been NASM. He also provided information and links regarding several other items. However, I should follow up on that in a different post. 

 

Thanks again Willi for the time and effort you put into searching for updates. It is a big help. :-)

 

 

Overview of changes in this Interim Build:

 


2024-04-30 21:54:27 suppls (shidel): relocated developer files from source to devel

2024-04-30 21:39:55 dojs (shidel): updated to v1.12.1 (The puny port)

2024-04-30 21:36:21 doszip (shidel): updated to v2.66

2024-04-30 21:32:30 testdisk (shidel): updated to v7.2 (final)

2024-04-30 21:27:47 fasm (shidel): updated to v1.73.32

2024-04-30 21:22:13 nasm (shidel): updated to v2.16.03

2024-04-13 07:11:10 nasm (shidel): updated to version 2.16.02

2024-04-04 20:33:02 project_FD-NLS (cardpuncher): Add files via upload

2024-04-04 16:14:11 project_FD-NLS (shidel): report update

2024-04-04 15:19:11 project_FD-NLS (shidel): Merge pull request #191 from cardpuncher/master

2024-04-03 20:02:23 project_FD-NLS (shidel): report update

2024-04-03 19:18:04 project_FD-NLS (shidel): Merge branch 'master' of github.com:shidel/fd-nls

2024-04-03 18:46:51 project_FD-NLS (shidel): FDNET DOSBox Staging Strings

2024-04-03 15:03:49 project_FD-NLS (shidel): Merge pull request #190 from cardpuncher/master

2024-04-03 15:02:20 fdnet [unstable] (shidel): DOSBox Staging networking support

2024-04-03 14:40:43 project_FDI [unstable] (shidel): DOSBox Hybrid install, FDAUTO path typo fix


 

Jerome
___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2405

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2405 for May is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


A special thanks to Wilhelm for pointing out most of the updates and providing 
links for me to download.

I’ve been very time constrained of late. Without his support, the only updated 
program in this Build would have been NASM. He also provided information and 
links regarding several other items. However, I should follow up on that in a 
different post. 

Thanks again Willi for the time and effort you put into searching for updates. 
It is a big help. :-)


Overview of changes in this Interim Build:

2024-04-30 21:54:27 suppls (shidel): relocated developer files from source to 
devel
2024-04-30 21:39:55 dojs (shidel): updated to v1.12.1 (The puny port)
2024-04-30 21:36:21 doszip (shidel): updated to v2.66
2024-04-30 21:32:30 testdisk (shidel): updated to v7.2 (final)
2024-04-30 21:27:47 fasm (shidel): updated to v1.73.32
2024-04-30 21:22:13 nasm (shidel): updated to v2.16.03
2024-04-13 07:11:10 nasm (shidel): updated to version 2.16.02
2024-04-04 20:33:02 project_FD-NLS (cardpuncher): Add files via upload
2024-04-04 16:14:11 project_FD-NLS (shidel): report update
2024-04-04 15:19:11 project_FD-NLS (shidel): Merge pull request #191 from 
cardpuncher/master
2024-04-03 20:02:23 project_FD-NLS (shidel): report update
2024-04-03 19:18:04 project_FD-NLS (shidel): Merge branch 'master' of 
github.com:shidel/fd-nls
2024-04-03 18:46:51 project_FD-NLS (shidel): FDNET DOSBox Staging Strings
2024-04-03 15:03:49 project_FD-NLS (shidel): Merge pull request #190 from 
cardpuncher/master
2024-04-03 15:02:20 fdnet [unstable] (shidel): DOSBox Staging networking support
2024-04-03 14:40:43 project_FDI [unstable] (shidel): DOSBox Hybrid install, 
FDAUTO path typo fix

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Windows for Workgroups howto

[Steve Nickolas via Freedos-devel]

On Sun, 28 Apr 2024, Eric Auer via Freedos-devel wrote:


- Use the Microsoft versions of HIMEM and EMM386 and SMARTDRV
  (bundled with Windows, alternatively from MIT-released MSDOS 4?)
  so update your config and autoexec accordingly


HIMEM 2.04 is included in 4.0, but it wasn't in the source drop. (The 
source to 2.03 has been out there, though; maybe Microsoft could be 
convinced to let that be dropped into the unofficial forks...)


Dunno if such an old version of himem, emm386 or smartdrv would work with 
Windows 3.x though, which is why they included them (or at least himem and 
smartdrv) with Windows...


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Windows for Workgroups howto

[Eric Auer via Freedos-devel]

Hi!

Hidden in the "Tyrian 2000 in DOS with sound on PCIe only machines?"
thread on BTTR which also contained the VSBHDA (soundblaster emulation
for HDA machines, Japheth's variant) announcement, I found this link:

https://github.com/pufengdu/RetroFuns/blob/main/WFWG/FDWFWG.md

it explains how to run Windows for Workgroups 3.11 with FreeDOS.
This could be a lot easier after updating our distro.

ECM has compiled our kernel with -DWIN31SUPPORT here:

https://pushbx.org/ecm/test/20230805.2/kwin31.zip

You also need ECM's improved SHARE compile:

https://pushbx.org/ecm/download/fdshare.zip

This already got some stackexchange coverage in 2023 here:

https://retrocomputing.stackexchange.com/questions/27480/how-to-use-start-windows-3-11-with-freedos

Now you can install Windows, but you have to select "return to DOS"
at the end of the install to modify settings before running Windows:

 - Use the Microsoft versions of HIMEM and EMM386 and SMARTDRV
   (bundled with Windows, alternatively from MIT-released MSDOS 4?)
   so update your config and autoexec accordingly

 - Edit SYSTEM.INI to comment out 3 drivers in the [386enh] block:

; Device=ifsmgr.286
; Device=vcache.386
; Device=vshare.386

 - In the same block, activate more compatible InDOS tracking:

InDOSPolling=True

Now Windows for Workgroups 3.11 should run with FreeDOS, even
on FAT32 drives, since you have deactivated some 386 protected
mode, FreeDOS-incompatible filesystem / cache / share drivers.

Do not enable 32BFA or 32BDA. Use only temporary swap files.

For proper Alt-Tab/Alt-Enter handling, use 4DOS instead of
FreeCOM, or press ENTER after each Alt-... sequence if you
want to stick to FreeCOM.

The howto described above also links to:

https://danielectra.github.io/blog/windows-31-on-freedos

this mentions that the relevant FreeDOS kernel patch dates back
to 2021-08-19, so it is a pity that this has still not become a
part of our standard distro. This 2022 howto also mentions that
the whole FreeDOS installer hangs, so the author had to install
FreeDOS in a VM and then copy the result to the real computer.

If you only want to use Windows 3.1, not Windows for Workgroups,
you can use the free open source HIMEMX :-) You do need that
InDOSPolling=True line, but you do not need to disable things.
SVGA 800x600 256 color drivers should work on common hardware.

Here is what Jeremy and ECM patched in the kernel in 2021:

https://github.com/FDOS/kernel/commit/9186e6c5ed1ab58bf1dc0497bacc352d3d758703

That improves InDOS and critical section handling, such as
int 2a.8001/8101 calls, indos flag updates, and adds
int 2f.13/16xx/46 support and int 13/19 vector tracking,
as well as a fix for int 2f.4a33 to clear BX now, etc.

Regards, Eric



PS: Another possibly interesting topic mentioned on BTTR is:

https://github.com/pufengdu/IO8EMMOK

which lets you use EMM386 with MS DOS 8 to run Windows 3.x on
8042 A20 style hardware UNLESS you have done the competing

https://msfn.org/board/topic/183250-how-to-disable-the-built-in-xms-driver-in-windows-mes-iosys

and only AFTER you have replaced, twice, 66 c7 46 49 ff ff by
6a ff 8f 46 49 90 in win386.exe for unknown reasons. That
io8emmok tool manipulates XMS, memory sizing and A20 things.

It also comes with a loader which performs an in-memory patch
to MS DOS in the HMA to fix compatibility, which changes:

cmp di,0x400 => change to 0x300
jnc +6
mov si,0x4
jmp -0x205
push ax
xor al,al
xchg al,[0xf5c]
pop ax
jz -0x12 => replace by NOPs

The BTTR user uses the following MS DOS 8, Win3.x config:

device=io8emmok.sys
device=emm386.exe noems
install=xmsres.exe 512
install=w3xstart.com

XMSRES is a tool by Japheth to limit visible XMS, here to
512 MB, because Windows would need config tricks to avoid
overflows in virtual memory / swap processing otherwise :-p

See also https://jeffpar.github.io/kbarchive/kb/084/Q84388/

and https://kb.iu.edu/d/abpe

You want to set PageOverCommit=1 or 2, not the default of 4,
in system.ini to make Win3 work with up to 1 GB of RAM. Our
HIMEM also has a /MAX=... option to globally limit XMS size.



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Wiki

[Jim Hall via Freedos-devel]

On Tue, Mar 26, 2024 at 5:25 PM Jerome Shidel via Freedos-devel
 wrote:
>
> Hi,
>
> Apparently, the (old) FreeDOS wiki on sourceforge is down or broken.
>
> After visiting the FreeDOS.org website, navigating to “Read the
> wiki” and waiting, I just get a blank page after redirection to the
>
> https://freedos.sourceforge.io/wiki/index.php/Main_Page web page.


I was *this* close to getting the last two guides ("Installing
FreeDOS" and "Networking FreeDOS") copied over, but ran out of time
because of some things at work. Then SourceForge broke something on
their end a few days ago. I'll do a selective Mediawiki upgrade on SF
over the weekend to get things back to a working state so I can
copy/paste the rest of the content.

The data is still there in the database, it's just that the PHP code
is barfing somewhere because the older Mediawiki doesn't seem to work
well on the newer PHP that SF upgraded to.

After I get those two guides copied over, I'll open it up to user
accounts to anyone who wants one. And I'll add a redirect to hide the
"w" in the URL, and change the "wiki" link on the www.freedos.org
website to point to the new website.

Any content after the two guides is pretty minor (command line usage,
etc) which can get moved over time.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Wiki

[Jerome Shidel via Freedos-devel]

Hi,

Apparently, the (old) FreeDOS wiki on sourceforge is down or broken. 

After visiting the FreeDOS.org  website, navigating to 
“Read the wiki ” and waiting, I just get a blank 
page after redirection to the

https://freedos.sourceforge.io/wiki/index.php/Main_Page 
 web page.

:-)

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki updates + questions

[Jim Hall via Freedos-devel]

> On Wednesday, March 20th, 2024 at 10:09 AM, Jim Hall via Freedos-devel 
>  wrote:
>
[..]
> > What to do about the "Networking How-to"? This is a collection of
> > pages that wasn't written as a typical "wiki" page (every page in a
> > wiki should stand on its own, with links to other pages for more info)
> > but as a series of pages that follow step 1, step 2, .. etc.
> >
> > Should I just copy/paste those pages into the new wiki, or move them
> > out into a new kind of "how-to" article?
> >
> > We have another collection of pages for an "Installation Guide" and I
> > have the same question there.
> >
> >
> > Related:
> >
> > I (and others) wrote a bunch of articles about FreeDOS for
> > Opensource.com before they stopped publishing (about a year ago).
> > Opensource.com is still up, and I'd like to copy/paste the FreeDOS
> > articles into a website that we control in case Opensource.com goes
> > away. At least the articles I wrote, and I can ask permission of other
> > authors if I have their contact info.
> >
[..]
> >
> > Should I just copy/paste those into the new wiki, or should I create a
> > new website to republish these, like a howto.freedos.org website .. or
> > maybe a "howto" directory on the new wiki website (but outside the
> > "wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory
> > on the main website, like www.freedos.org/howto .. what's the best
> > plan?
[..]

On Wed, Mar 20, 2024 at 1:50 PM Mercury Thirteen via Freedos-devel
 wrote:
> Personally, I'm a big fan of keeping information in one easy to access
> place. If it were me, I would put the articles in their own section
> on the wiki under a helpful title, where they could also be linked to
> from other articles in the wiki, e.g. an article on how to install
> FreeDOS could link to How-Tos detailing how one would partition and
> format their drive. I'm no SEO expert by far, but I would think that
> the fact that the articles are not simply copy-pasted but are also
> linked to from other pages on the site - not to mention that there
> is a ton of other content on the wiki, making it more than a simple
> copy-paste ripoff of the source site - would mitigate the down-ranking
> which Google et al. may otherwise do.


I'm definitely a fan of not adding more work for myself. :-)

Adding the how-to articles inside the wiki seems like a good idea,
then. And that way, it keeps all documentation in one place. Maybe
I'll create a "parent" entry like "Howto" and copy/paste all the other
how-to articles under that so you have paths like
wiki.freedos.org/Howto/(topic) or whatever.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS wiki updates + questions

[Mercury Thirteen via Freedos-devel]

Personally, I'm a big fan of keeping information in one easy to access place. 
If it were me, I would put the articles in their own section on the wiki under 
a helpful title, where they could also be linked to from other articles in the 
wiki, e.g. an article on how to install FreeDOS could link to How-Tos detailing 
how one would partition and format their drive. I'm no SEO expert by far, but I 
would think that the fact that the articles are not simply copy-pasted but are 
also linked to from other pages on the site - not to mention that there is a 
ton of other content on the wiki, making it more than a simple copy-paste 
ripoff of the source site - would mitigate the down-ranking which Google et al. 
may otherwise do.




Sent with Proton Mail secure email.

On Wednesday, March 20th, 2024 at 10:09 AM, Jim Hall via Freedos-devel 
 wrote:

> I've been moving the FreeDOS wiki content over by copy/paste. And I've
> finished almost all of the tricky pages .. then it's a collection of
> small pages (mostly usage pages for programs) which I think should go
> quickly. Then I'll add wiki editor accounts for anyone who wants them.
> 
> The new wiki will be here:
> https://wiki.freedos.org/w/index.php?title=Main_Page
> 
> (don't bookmark that yet .. the "w" part in the URL will likely go away)
> 
> 
> Question:
> 
> What to do about the "Networking How-to"? This is a collection of
> pages that wasn't written as a typical "wiki" page (every page in a
> wiki should stand on its own, with links to other pages for more info)
> but as a series of pages that follow step 1, step 2, .. etc.
> 
> Should I just copy/paste those pages into the new wiki, or move them
> out into a new kind of "how-to" article?
> 
> We have another collection of pages for an "Installation Guide" and I
> have the same question there.
> 
> 
> Related:
> 
> I (and others) wrote a bunch of articles about FreeDOS for
> Opensource.com before they stopped publishing (about a year ago).
> Opensource.com is still up, and I'd like to copy/paste the FreeDOS
> articles into a website that we control in case Opensource.com goes
> away. At least the articles I wrote, and I can ask permission of other
> authors if I have their contact info.
> 
> Again, these aren't written to be "wiki" pages, they are standalone
> articles about how to do something in FreeDOS (like how to use CD and
> DIR, other useful commands, conio programming, .. etc) in 800 to 1000
> words.
> https://opensource.com/tags/freedos
> 
> Should I just copy/paste those into the new wiki, or should I create a
> new website to republish these, like a howto.freedos.org website .. or
> maybe a "howto" directory on the new wiki website (but outside the
> "wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory
> on the main website, like www.freedos.org/howto .. what's the best
> plan? Since Google's "SEO" ranking generally "down-ranks" websites
> that copy/paste content from other websites, creating a new website
> name like howto.freedos.org seems like a good idea, but I don't want
> to create a bunch of work for myself if others have a better idea
> 
> 
> Jim
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS wiki updates + questions

[Jim Hall via Freedos-devel]

I've been moving the FreeDOS wiki content over by copy/paste. And I've
finished almost all of the tricky pages .. then it's a collection of
small pages (mostly usage pages for programs) which I think should go
quickly. Then I'll add wiki editor accounts for anyone who wants them.

The new wiki will be here:
https://wiki.freedos.org/w/index.php?title=Main_Page

(don't bookmark that yet .. the "w" part in the URL will likely go away)


Question:

What to do about the "Networking How-to"? This is a collection of
pages that wasn't written as a typical "wiki" page (every page in a
wiki should stand on its own, with links to other pages for more info)
but as a series of pages that follow step 1, step 2, .. etc.

Should I just copy/paste those pages into the new wiki, or move them
out into a new kind of "how-to" article?

We have another collection of pages for an "Installation Guide" and I
have the same question there.


Related:

I (and others) wrote a bunch of articles about FreeDOS for
Opensource.com before they stopped publishing (about a year ago).
Opensource.com is still up, and I'd like to copy/paste the FreeDOS
articles into a website that we control in case Opensource.com goes
away. At least the articles I wrote, and I can ask permission of other
authors if I have their contact info.

Again, these aren't written to be "wiki" pages, they are standalone
articles about how to do something in FreeDOS (like how to use CD and
DIR, other useful commands, conio programming, .. etc) in 800 to 1000
words.
https://opensource.com/tags/freedos

Should I just copy/paste those into the new wiki, or should I create a
new website to republish these, like a howto.freedos.org website .. or
maybe a "howto" directory on the new wiki website (but outside the
"wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory
on the main website, like www.freedos.org/howto .. what's the best
plan? Since Google's "SEO" ranking generally "down-ranks" websites
that copy/paste content from other websites, creating a new website
name like howto.freedos.org seems like a good idea, but I don't want
to create a bunch of work for myself if others have a better idea


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2403

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2403 for March is now available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes:

* Primarily, the release was switched back to HTMLHELP from AMB based Help. The 
new version of help needs testing and checking of the English text. I don’t 
think the other languages have received any significant changes and are waiting 
on verification of the English text before being translated.

2024-02-23 07:30:44 fdhelper [unstable] (Shidel): Merge branch 'unstable' into 
'unstable'
2024-02-23 07:02:54 append (shidel): updated to v5.0-0.7 (FCB bugfix)
2024-02-23 03:23:50 append (shidel): Merge branch 'master' of 
gitlab.com:FreeDOS/base/append
2024-02-23 03:23:35 append (shidel): update primary site information in metadata
2024-02-23 02:22:22 project_FDI-x86 [unstable] (shidel): Merge pull request #6 
from boeckmann/unstable
2024-02-23 02:12:13 project_FDI [unstable] (shidel): Merge pull request #20 
from boeckmann/unstable
2024-02-22 21:07:41 project_FDI [unstable] (Bernd Boeckmann): change help 
viewer to HTMLVIEW
2024-02-22 20:54:27 fdhelper [unstable] (Bernd Boeckmann): help.bat: prioritize 
HTMLHELP
2024-02-22 19:43:20 project_FDI-x86 [unstable] (Bernd Boeckmann): change help 
viewer to htmlhelp
2024-02-22 19:18:01 fdisk [unstable] (Bernd Boeckmann): update LSM
2024-02-22 19:15:15 fdisk [unstable] (Bernd Boeckmann): release 1.3.14 part2
2024-02-22 19:12:05 fdisk [unstable] (Bernd Boeckmann): release 1.3.14
2024-02-21 09:27:56 append (Shidel): Merge branch 'master' into 'master'
2024-02-21 09:27:55 append (tsupplis): Update INT21.ASM -  Major Logic Fix for 
support of FCB I/O calls
2024-02-18 04:31:39 tree [unstable] (shidel): updated to v3.7.3
2024-02-17 14:02:53 debug (shidel): updated to v2.02
2024-02-17 09:20:06 fbc_help (shidel): added override to package structure 
verification
2024-02-17 09:09:57 fbc_help (shidel): added package config file
2024-02-17 08:17:14 blocek (shidel): updated to v1.75b
2024-02-17 07:43:14 jemm (shidel): updated to v5.84
2024-02-09 20:35:19 htmlhelp [unstable] (Bernd Boeckmann): update English help 
to 1.1.0 (preview)
2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS package data fork, sort of

[Jim Hall via Freedos-devel]

Hi Eric

This is a really interesting effort and I think it would be good to
find a way to get Willi's efforts integrated somehow into the
changelog for the monthly test releases. But as you've mentioned,
there's a lot of overlap here. I think the right place to start is to
talk about it. But we NEED TO HAVE THE CONVERSATION ON THE EMAIL LIST,
so everyone can see it and talk about it. That's how "open source"
works.

I don't know the right solution to this, but if we DISCUSS IT TOGETHER
ON THE EMAIL LIST we can figure it out. I imagine there's a way that
Willi might create a file (export from his spreadsheet? or some other
method?) in some format that the automated distro build system can
read, and collate the data into the changelog that way.



On Thu, Feb 1, 2024 at 4:18 PM Eric Auer  wrote:
>
>
> Hi Jim, Willi is working on a spreadsheet which lists:
>
> website, our gitlab copy URL *or* some contact info or alternate URL,
> creator / maintainer, version (in distro versus upstream) and license
>
> for most of the packages in our distro. This seems to overlap
> heavily with metadata in our LSM, so it would be good if we
> could combine the data sources somehow. In other words: The
> spreadsheet info could be added to our LSM and cases where
> the upstream version is newer than ours could be updated.
>
> Conversely, Willi might be duplicating efforts in finding
> package URL, maintainers and contacts in cases where those
> listed in the LSM are still valid, so those could be added
> to his spreadsheet.
>
> In general, I sense some risks of duplicate work here! Who
> would be the right people to contact to get both metadata
> "repositories" merged? Our LSM and that spreadsheet, that
> is? And who and how generates our HTML from LSM these days?
>
> Background is that I would *really* like to get changelog
> info when packages get updated. The automated mails that
> get triggered by Jerome's toolchain just tell me THAT a
> new version got published, and which, but not WHY, nor
> WHAT changed in that. So Willi sent me that table in the
> hope that it could help me answer the question, while I
> think he should not be putting all that effort in some
> SEPARATE data table in the first place, but merge that.
>
> Regards, Eric
>


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Eric Auer via Freedos-devel]

Hi Jerome,


For these: They are version updates.


2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21



As for what specifically changed in each of those version updates, I couldn’t 
say.


Exactly that would have been my specific question. Who could answer it?


You would need to check the change log (if any) that is included in the 
respective package.


Yet you have added those updates, so I would have expected you to know?

Can you provide links to the changelogs so somebody who is less
into programming but still wants to help could summarize them
for this mailing list?

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Jerome Shidel via Freedos-devel]

Hi Eric, 

> On Feb 1, 2024, at 9:32 AM, Eric Auer via Freedos-devel 
>  wrote:
> 
> 
> Hi Jerome, thanks for the updates! :-)
> 
>> The FreeDOS Interim Test Build T2402 for February is now available for 
>> download at:
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 
>> 
>> Changes since T2401:
> 
> What specifically has changed in those packages?

For these: They are version updates. 

>> 2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
>> 2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
>> 2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
>> 2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
>> 2024-02-01 05:17:54 sleep (shidel): updated to 1.1
>> 2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
>> 2024-01-31 18:00:28 lzop (shidel): updated to 1.04
>> 2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21

For these: They are translation file and package description updates.

>> 2024-01-31 17:27:19 sqlite (shidel): TR package description updated
>> 2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
>> 2024-01-31 17:22:46 clamdb (shidel): TR package description updated
>> 2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
>> cardpuncher/master
>> 2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
>> andrewbird/kittenc-fixup
>> Thanks to Willi for pointing out the software that needed updated.
>> Jerome
> 

As for what specifically changed in each of those version updates, I couldn’t 
say. 

You would need to check the change log (if any) that is included in the 
respective package. 

With the wide range of text formatting and locations used by individual 
projects, I have not attempted to automate a method to parse individual project 
change logs to create a detailed summary of individual project changes. 

Although there is a lot of automation that is performed when I update packages, 
the overall process is still very time consuming. For example, from start to 
finish these few updates still took about 7 hours (from start to finish) to 
perform. However, a good piece of that time (maybe 3+ hours) was used by the 
automated tools chewing on the FreeBASIC files for things like timestamp 
preservation. 

Unfortunately, I just cannot dedicate the time required to cobble together such 
a detailed change list manually.

Thankfully, the entire process for both Interim Test Builds and Actual Release 
Builds is fully automated. All I need to do is fire up a related virtual 
machine and run “make”. The RBE will perform all the work to configure things 
and assemble a release from scratch. I come back an hour or so later and if 
there were no package or other issues (like size limitations) a release will be 
waiting.

Jerome





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2402

[Eric Auer via Freedos-devel]

Hi Jerome, thanks for the updates! :-)


The FreeDOS Interim Test Build T2402 for February is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes since T2401:


What specifically has changed in those packages?


2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21
2024-01-31 17:27:19 sqlite (shidel): TR package description updated
2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
2024-01-31 17:22:46 clamdb (shidel): TR package description updated
2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
cardpuncher/master
2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
andrewbird/kittenc-fixup

Thanks to Willi for pointing out the software that needed updated.

Jerome






___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2402

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2402 for February is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Changes since T2401:

2024-02-01 05:49:48 upx (shidel): updated to 4.2.2
2024-02-01 05:44:35 liquiwar (shidel): updated to 5.6.4
2024-02-01 05:38:55 testdisk (shidel): updated to 7.2
2024-02-01 05:33:34 fbc_help (shidel): updated to 1.10.1
2024-02-01 05:17:54 sleep (shidel): updated to 1.1
2024-02-01 05:17:06 fbc (shidel): updated to 1.10.1
2024-01-31 18:00:28 lzop (shidel): updated to 1.04
2024-01-31 17:51:24 lzip (shidel): updated to LZIP 1.20 and LZIPRECOVER 1.21
2024-01-31 17:27:19 sqlite (shidel): TR package description updated
2024-01-31 17:26:41 fdnpkg (shidel): TR translation update
2024-01-31 17:22:46 clamdb (shidel): TR package description updated
2024-01-31 17:13:40 project_FD-NLS (shidel): Merge pull request #185 from 
cardpuncher/master
2024-01-31 17:11:54 project_FD-NLS (shidel): Merge pull request #183 from 
andrewbird/kittenc-fixup

Thanks to Willi for pointing out the software that needed updated.

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Book8088

[Louis Santillan via Freedos-devel]

That works.

On Tue, Jan 30, 2024 at 12:12 PM Jim Hall via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> [resending without photo attached]
>
>
> On Tue, Jan 30, 2024 at 2:06 PM Jim Hall  wrote:
> >
> > Very helpful. I thought it might be something like this. I'll update the
> bug with your info.
> >
> > Mind if I copy your photo into the bug report to show that it's working?
> >
> > On Tue, Jan 30, 2024, 1:44 PM Louis Santillan 
> wrote:
> >>
> >> I have a Book8088 v2.  I did some testing.  I imaged the FD13BOOT.IMG
> from FD 1.3 Floppy Edition[0] to my a slot on my Gotek formatted USB
> stick.  I then used a Dell 316SX (a 386) with a Gotek FDD emulator & XT-IDE
> r625 to boot FD v1.3 over floppy.  Next, I FDISK'd a 256MB CF card as FAT16
> (CHS 984/16/32).  Rebooted again to floppy and then ran `format C:/q/s`.  I
> then copied a few binaries from the FD floppy to the CF card.  Rebooted to
> verify the 256MB CF card would boot and it worked.
> >>
> >> Finally, popped out the CF card of the 316SX and placed it in the slot
> on the Book8088.  Booted & it worked.  See the pic below for reference.
> >>
> >> No magic other than I've been working to restore the Dell 316SX so it
> now has a NIC with the XT-IDE r625 BIOS in it's ROM slot.  The original
> 3.5" & 5.25" drives aren't spinning and I need to refurb those next.
> >>
> >> The user on SF could try imaging a small (<2GB) USB stick with
> FD13BOOT.IMG and try booting off that as well.  It might take a reflash of
> the BIOS [1]. They'll need to hit 'A' quickly to redirect XT-IDE to boot
> off floppy instead of the CF.  I might test that as well.
> >>
> >>
> >>
> >>
> >> [0]
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-FloppyEdition.zip
> >> [1]
> https://forum.vcfed.org/index.php?threads/book-8088-discovery-and-modification-thread.1245155/post-1343495
> >>
> >> On Tue, Jan 30, 2024 at 8:23 AM Jim Hall via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
> >>>
> >>> A user entered a bug that FreeDOS won't boot on the Book8088.
> >>> https://sourceforge.net/p/freedos/bugs/391/
> >>>
> >>> > Hi. I got myself a Book8088 2.0 recently. It's a Chinese retro
> computer
> >>> > with a NEC V20 processor, 640 kb ram and a CF card as a storage. It
> uses
> >>> > Sergei Kiselev's BIOS_8088 with XTIDE extensions (which enable
> straight
> >>> > up boot from CF card(.
> >>> >
> >>> > I tried multiple versions of 16-bit FreeDOS kernels (2039-2043) on
> it,
> >>> > but they all get stuck at InitDisk function. It will actually print
> out
> >>> > the partition and detect CHS parameters but will get confused by it
> and
> >>> > try to "correct" it. That will cause it to get stuck.
> >>> >
> >>> > This little laptop came preinstalled with MS-DOS 6.22 and that works
> ok.
> >>> >
> >>> > Btw, It doesn't have an alternative IDE interface, so the CF card is
> >>> > only means of storage.
> >>> >
> >>> > Also, the error still appears even if CF card is formatted as either
> >>> > FAT16 or FAT32.
> >>>
> >>> Does anyone have one of these devices, or have more details about the
> >>> internals? I know about this only from what I've seen on Facebook:
> >>> it's a mini-laptop made from retro hardware with a CF card for
> >>> storage, but no floppy.
> >>>
> >>> The bug report indicates that FreeDOS is stopping at the InitDisk
> function.
> >>>
> >>> The user reports that the device uses a CF card in a CF-to-IDE adapter
> >>> to act as storage ("hard drive"). At my first guess, that's probably
> >>> the issue. I know others have had mixed results with CF-to-IDE,
> >>> usually because the CF-to-IDE isn't correctly emulating IDE or because
> >>> the BIOS doesn't recognize the CF-to-IDE correctly. (Seems like
> >>> neither is the case here, since the user reports the Book8088 came
> >>> with a working copy of pre-installed MS-DOS.)
> >>>
> >>> I think other issues folks have had with CF storage is that the CF
> >>> isn't set up right, so it has an incorrect partition table boundary,
> >>> or something like that.
> >>>
> >>> My first guess is to ask the user to try a different CF card than the
> >>> one they are using now, to see if it's an issue with the CF card
> >>> itself.
> >>>
> >>> Suggestions?
> >>>
> >>>
> >>> ___
> >>> Freedos-devel mailing list
> >>> Freedos-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Book8088

[Jim Hall via Freedos-devel]

[resending without photo attached]


On Tue, Jan 30, 2024 at 2:06 PM Jim Hall  wrote:
>
> Very helpful. I thought it might be something like this. I'll update the bug 
> with your info.
>
> Mind if I copy your photo into the bug report to show that it's working?
>
> On Tue, Jan 30, 2024, 1:44 PM Louis Santillan  wrote:
>>
>> I have a Book8088 v2.  I did some testing.  I imaged the FD13BOOT.IMG from 
>> FD 1.3 Floppy Edition[0] to my a slot on my Gotek formatted USB stick.  I 
>> then used a Dell 316SX (a 386) with a Gotek FDD emulator & XT-IDE r625 to 
>> boot FD v1.3 over floppy.  Next, I FDISK'd a 256MB CF card as FAT16 (CHS 
>> 984/16/32).  Rebooted again to floppy and then ran `format C:/q/s`.  I then 
>> copied a few binaries from the FD floppy to the CF card.  Rebooted to verify 
>> the 256MB CF card would boot and it worked.
>>
>> Finally, popped out the CF card of the 316SX and placed it in the slot on 
>> the Book8088.  Booted & it worked.  See the pic below for reference.
>>
>> No magic other than I've been working to restore the Dell 316SX so it now 
>> has a NIC with the XT-IDE r625 BIOS in it's ROM slot.  The original 3.5" & 
>> 5.25" drives aren't spinning and I need to refurb those next.
>>
>> The user on SF could try imaging a small (<2GB) USB stick with FD13BOOT.IMG 
>> and try booting off that as well.  It might take a reflash of the BIOS [1]. 
>> They'll need to hit 'A' quickly to redirect XT-IDE to boot off floppy 
>> instead of the CF.  I might test that as well.
>>
>>
>>
>>
>> [0] 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-FloppyEdition.zip
>> [1] 
>> https://forum.vcfed.org/index.php?threads/book-8088-discovery-and-modification-thread.1245155/post-1343495
>>
>> On Tue, Jan 30, 2024 at 8:23 AM Jim Hall via Freedos-devel 
>>  wrote:
>>>
>>> A user entered a bug that FreeDOS won't boot on the Book8088.
>>> https://sourceforge.net/p/freedos/bugs/391/
>>>
>>> > Hi. I got myself a Book8088 2.0 recently. It's a Chinese retro computer
>>> > with a NEC V20 processor, 640 kb ram and a CF card as a storage. It uses
>>> > Sergei Kiselev's BIOS_8088 with XTIDE extensions (which enable straight
>>> > up boot from CF card(.
>>> >
>>> > I tried multiple versions of 16-bit FreeDOS kernels (2039-2043) on it,
>>> > but they all get stuck at InitDisk function. It will actually print out
>>> > the partition and detect CHS parameters but will get confused by it and
>>> > try to "correct" it. That will cause it to get stuck.
>>> >
>>> > This little laptop came preinstalled with MS-DOS 6.22 and that works ok.
>>> >
>>> > Btw, It doesn't have an alternative IDE interface, so the CF card is
>>> > only means of storage.
>>> >
>>> > Also, the error still appears even if CF card is formatted as either
>>> > FAT16 or FAT32.
>>>
>>> Does anyone have one of these devices, or have more details about the
>>> internals? I know about this only from what I've seen on Facebook:
>>> it's a mini-laptop made from retro hardware with a CF card for
>>> storage, but no floppy.
>>>
>>> The bug report indicates that FreeDOS is stopping at the InitDisk function.
>>>
>>> The user reports that the device uses a CF card in a CF-to-IDE adapter
>>> to act as storage ("hard drive"). At my first guess, that's probably
>>> the issue. I know others have had mixed results with CF-to-IDE,
>>> usually because the CF-to-IDE isn't correctly emulating IDE or because
>>> the BIOS doesn't recognize the CF-to-IDE correctly. (Seems like
>>> neither is the case here, since the user reports the Book8088 came
>>> with a working copy of pre-installed MS-DOS.)
>>>
>>> I think other issues folks have had with CF storage is that the CF
>>> isn't set up right, so it has an incorrect partition table boundary,
>>> or something like that.
>>>
>>> My first guess is to ask the user to try a different CF card than the
>>> one they are using now, to see if it's an issue with the CF card
>>> itself.
>>>
>>> Suggestions?
>>>
>>>
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS on Book8088

[Louis Santillan via Freedos-devel]

Louis Santillan 
11:44 AM (5 minutes ago)
to Technical, Jim
I have a Book8088 v2.  I did some testing.  I imaged the FD13BOOT.IMG from
FD 1.3 Floppy Edition[0] to my a slot on my Gotek formatted USB stick.  I
then used a Dell 316SX (a 386) with a Gotek FDD emulator & XT-IDE r625 to
boot FD v1.3 over floppy.  Next, I FDISK'd a 256MB CF card as FAT16 (CHS
984/16/32).  Rebooted again to floppy and then ran `format C:/q/s`.  I then
copied a few binaries from the FD floppy to the CF card.  Rebooted to
verify the 256MB CF card would boot and it worked.

Finally, popped out the CF card of the 316SX and placed it in the slot on
the Book8088.  Booted & it worked[1][2].  See the pic below for reference.

No magic other than I've been working to restore the Dell 316SX so it now
has a NIC with the XT-IDE r625 BIOS in it's ROM slot.  The original 3.5" &
5.25" drives aren't spinning and I need to refurb those next.

The user on SF could try imaging a small (<2GB) USB stick with
FD13BOOT.IMG and try booting off that as well [3].  It might take a reflash
of the BIOS. They'll need to hit 'A' quickly to redirect XT-IDE to boot off
floppy instead of the CF.  I might test that as well.


[0]
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/FD13-FloppyEdition.zip
[1]
https://drive.google.com/file/d/1Vq2RvNgPNxrCOuVEFDruw4NwJYCh4Zvv/view?usp=drive_link
[2]
https://drive.google.com/file/d/1NsKzz5WK4fw_wn-2WBnaH8sTsIyGs-ZN/view?usp=drive_link
[3]
https://forum.vcfed.org/index.php?threads/book-8088-discovery-and-modification-thread.1245155/post-1343495

On Tue, Jan 30, 2024 at 8:23 AM Jim Hall via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> A user entered a bug that FreeDOS won't boot on the Book8088.
> https://sourceforge.net/p/freedos/bugs/391/
>
> > Hi. I got myself a Book8088 2.0 recently. It's a Chinese retro computer
> > with a NEC V20 processor, 640 kb ram and a CF card as a storage. It uses
> > Sergei Kiselev's BIOS_8088 with XTIDE extensions (which enable straight
> > up boot from CF card(.
> >
> > I tried multiple versions of 16-bit FreeDOS kernels (2039-2043) on it,
> > but they all get stuck at InitDisk function. It will actually print out
> > the partition and detect CHS parameters but will get confused by it and
> > try to "correct" it. That will cause it to get stuck.
> >
> > This little laptop came preinstalled with MS-DOS 6.22 and that works ok.
> >
> > Btw, It doesn't have an alternative IDE interface, so the CF card is
> > only means of storage.
> >
> > Also, the error still appears even if CF card is formatted as either
> > FAT16 or FAT32.
>
> Does anyone have one of these devices, or have more details about the
> internals? I know about this only from what I've seen on Facebook:
> it's a mini-laptop made from retro hardware with a CF card for
> storage, but no floppy.
>
> The bug report indicates that FreeDOS is stopping at the InitDisk function.
>
> The user reports that the device uses a CF card in a CF-to-IDE adapter
> to act as storage ("hard drive"). At my first guess, that's probably
> the issue. I know others have had mixed results with CF-to-IDE,
> usually because the CF-to-IDE isn't correctly emulating IDE or because
> the BIOS doesn't recognize the CF-to-IDE correctly. (Seems like
> neither is the case here, since the user reports the Book8088 came
> with a working copy of pre-installed MS-DOS.)
>
> I think other issues folks have had with CF storage is that the CF
> isn't set up right, so it has an incorrect partition table boundary,
> or something like that.
>
> My first guess is to ask the user to try a different CF card than the
> one they are using now, to see if it's an issue with the CF card
> itself.
>
> Suggestions?
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS on Book8088

[Jim Hall via Freedos-devel]

A user entered a bug that FreeDOS won't boot on the Book8088.
https://sourceforge.net/p/freedos/bugs/391/

> Hi. I got myself a Book8088 2.0 recently. It's a Chinese retro computer
> with a NEC V20 processor, 640 kb ram and a CF card as a storage. It uses
> Sergei Kiselev's BIOS_8088 with XTIDE extensions (which enable straight
> up boot from CF card(.
>
> I tried multiple versions of 16-bit FreeDOS kernels (2039-2043) on it,
> but they all get stuck at InitDisk function. It will actually print out
> the partition and detect CHS parameters but will get confused by it and
> try to "correct" it. That will cause it to get stuck.
>
> This little laptop came preinstalled with MS-DOS 6.22 and that works ok.
>
> Btw, It doesn't have an alternative IDE interface, so the CF card is
> only means of storage.
>
> Also, the error still appears even if CF card is formatted as either
> FAT16 or FAT32.

Does anyone have one of these devices, or have more details about the
internals? I know about this only from what I've seen on Facebook:
it's a mini-laptop made from retro hardware with a CF card for
storage, but no floppy.

The bug report indicates that FreeDOS is stopping at the InitDisk function.

The user reports that the device uses a CF card in a CF-to-IDE adapter
to act as storage ("hard drive"). At my first guess, that's probably
the issue. I know others have had mixed results with CF-to-IDE,
usually because the CF-to-IDE isn't correctly emulating IDE or because
the BIOS doesn't recognize the CF-to-IDE correctly. (Seems like
neither is the case here, since the user reports the Book8088 came
with a working copy of pre-installed MS-DOS.)

I think other issues folks have had with CF storage is that the CF
isn't set up right, so it has an incorrect partition table boundary,
or something like that.

My first guess is to ask the user to try a different CF card than the
one they are using now, to see if it's an issue with the CF card
itself.

Suggestions?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2401

[Jim Hall via Freedos-devel]

On Mon, Jan 1, 2024 at 7:46 AM Jerome Shidel via Freedos-devel
 wrote:
>
> The FreeDOS Interim Test Build T2401 for January is now available for
> download at:
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
>
> Although this update consists of only a few simple changes, it is an
> important update from T2312.
>
> There were several packages that erroneously included a ‘.DATESTAMP’
[..]
> Unlike the large number of updates in T2312, there were no other
> significant or package updates in T2401.


Yay, thanks! I've grabbed the new version and am installing it now. I
don't usually do a 'full install' - usually just 'plain DOS' plus a
few packages that I use all the time - so I haven't encountered the
.DATESTAMP issue before. But I'll reply here if I see anything amiss.



Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2401

[Jerome Shidel via Freedos-devel]

The FreeDOS Interim Test Build T2401 for January is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Although this update consists of only a few simple changes, it is an important 
update from T2312.

There were several packages that erroneously included a ‘.DATESTAMP’ file. 
During installation of those packages it could cause a file conflict and 
failure to install some packages. The file was not related to package 
management or the ’.TIMESTAMP’ file used to preserve file date time stamps when 
working with version control systems. It was from a different utility and meant 
for local system usage only. I think I purged all of them. If I missed any, 
please let me know.

Unlike the large number of updates in T2312, there were no other significant or 
package updates in T2401.

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Interim Build T2312

[Jerome Shidel via Freedos-devel]

Minor correction in T2312 notice email...

> On Dec 2, 2023, at 3:58 PM, Jerome Shidel via Freedos-devel 
>  wrote:
> 
> Hi All, 
> 
> The FreeDOS Interim Test Build T2312 for December is now available for 
> download at:
> 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
> 
> Sorry, it is a day late. I’ve been occupied with other things.
> 
> Thank you Willi for the reminder. :-)
> 
> There are a bunch of updated programs this month:
> 
> 2023-11-22 21:20:33 fdisk [unstable] (Bernd Boeckmann): release 1.3.11
> 2023-11-22 03:16:29 doszip (shidel): updated to v2.65
> 2023-11-21 10:05:28 nethack (shidel): update to v3.6.7
> 2023-11-21 09:26:59 empong (shidel): updated to v0.92
> 2023-11-21 09:18:46 dosdef (shidel): updated to v1.1.0
> 2023-11-21 09:07:17 utf8tocp (shidel): updated to v0.9.5
> 2023-11-21 04:10:45 curl (shidel): updated to v8.4.0
> 2023-11-21 02:51:20 edlin (shidel): updated to v2.23
> 2023-11-20 21:05:29 links (shidel): updated to v2.29
> 2023-11-20 20:00:09 dosmid (shidel): updated to v0.9.7
> 2023-11-20 10:03:00 upx (shidel): updated to v4.2.1
> 
> Plus some new language translations:
> 
> 2023-11-20 13:29:16 doslfn (shidel): updated NLS
> 2023-11-20 12:18:29 usbdos (shidel): added NL translation
> 2023-11-20 11:46:49 fdisk [unstable] (shidel): added NL translation
> 2023-11-20 11:44:24 fdshell (shidel): added NL translation
> 2023-11-20 11:40:05 mirror (shidel): added NL translation
> 2023-11-20 10:10:17 label (shidel): added NL translation
> 2023-11-13 22:21:14 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to label
> 2023-11-12 01:14:20 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to fdshell
> 2023-11-12 01:07:53 project_FD-NLS (Gert Van Waelvelde): Add Dutch 
> translation to dosusb.
> 2023-11-12 00:35:23 project_FD-NLS (Gert Van Waelvelde): Create mirror.nl
> 2023-11-12 00:17:11 project_FD-NLS (Gert Van Waelvelde): Create fdisk.nl
> 2023-11-01 06:08:38 dojs (shidel): Updated to version 1.11.0

dojs should be in the first list with the other updated programs. :-)

That makes 12 updates for this month. 

It might keep you busy through DOSember. 

:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Interim Build T2312

[Jerome Shidel via Freedos-devel]

Hi All, 

The FreeDOS Interim Test Build T2312 for December is now available for download 
at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Sorry, it is a day late. I’ve been occupied with other things.

Thank you Willi for the reminder. :-)

There are a bunch of updated programs this month:

2023-11-22 21:20:33 fdisk [unstable] (Bernd Boeckmann): release 1.3.11
2023-11-22 03:16:29 doszip (shidel): updated to v2.65
2023-11-21 10:05:28 nethack (shidel): update to v3.6.7
2023-11-21 09:26:59 empong (shidel): updated to v0.92
2023-11-21 09:18:46 dosdef (shidel): updated to v1.1.0
2023-11-21 09:07:17 utf8tocp (shidel): updated to v0.9.5
2023-11-21 04:10:45 curl (shidel): updated to v8.4.0
2023-11-21 02:51:20 edlin (shidel): updated to v2.23
2023-11-20 21:05:29 links (shidel): updated to v2.29
2023-11-20 20:00:09 dosmid (shidel): updated to v0.9.7
2023-11-20 10:03:00 upx (shidel): updated to v4.2.1

Plus some new language translations:

2023-11-20 13:29:16 doslfn (shidel): updated NLS
2023-11-20 12:18:29 usbdos (shidel): added NL translation
2023-11-20 11:46:49 fdisk [unstable] (shidel): added NL translation
2023-11-20 11:44:24 fdshell (shidel): added NL translation
2023-11-20 11:40:05 mirror (shidel): added NL translation
2023-11-20 10:10:17 label (shidel): added NL translation
2023-11-13 22:21:14 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to label
2023-11-12 01:14:20 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to fdshell
2023-11-12 01:07:53 project_FD-NLS (Gert Van Waelvelde): Add Dutch translation 
to dosusb.
2023-11-12 00:35:23 project_FD-NLS (Gert Van Waelvelde): Create mirror.nl
2023-11-12 00:17:11 project_FD-NLS (Gert Van Waelvelde): Create fdisk.nl
2023-11-01 06:08:38 dojs (shidel): Updated to version 1.11.0

:-)

Jerome


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Source

[robert roper via Freedos-devel]

I just ordered a few, one is called "Undocumented DOS".  I found another
called RxDOS that sounds like they did something similar with trying to
recreate DOS.

I really appreciate both of you taking the time to help!


Rob

On Fri, Dec 1, 2023 at 11:18 AM tom ehlert via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
> > Is there a FreeDOS walk thru of the source code that you would consider
> > helpful to the uninitiated?
> if you mean the *kernel* source, please say so.
>
>
>
> > I want to start down the road to more bare
> > metal coding and would love to be able to help with FreeDOS in the far
> > future but I'm not sure where to begin.  I do know how to program in C
> and
> > have just purchased some old 8086 assembly books to start learning that
> but
> > none of them talk about operating system concepts.
> > I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds
> > perfect, except it was published in 1996.  Is there anything like this
> that
> > is more current?  Or do you consider that the definitive guide?
>
> even as the book is quite old, it's the best (ecause only) gde you wll
> find.
> even as there has been many changes since 1996, the general structure of
> the kernel
> is mostly the same.
> you will also need some book(s) with 'DOS programming explained' and
> 'undocumented'
> in their title to make sense of the kernel source.
>
> Tom
>
>
>
> ___________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Source

[tom ehlert via Freedos-devel]

> Is there a FreeDOS walk thru of the source code that you would consider
> helpful to the uninitiated?  
if you mean the *kernel* source, please say so.



> I want to start down the road to more bare
> metal coding and would love to be able to help with FreeDOS in the far
> future but I'm not sure where to begin.  I do know how to program in C and
> have just purchased some old 8086 assembly books to start learning that but
> none of them talk about operating system concepts.
> I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds
> perfect, except it was published in 1996.  Is there anything like this that
> is more current?  Or do you consider that the definitive guide?

even as the book is quite old, it's the best (ecause only) gde you wll find.
even as there has been many changes since 1996, the general structure of the 
kernel 
is mostly the same.
you will also need some book(s) with 'DOS programming explained' and 
'undocumented'
in their title to make sense of the kernel source.

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Source

[robert roper via Freedos-devel]

Thanks so much for your reply!

On Wed, Nov 29, 2023 at 7:51 PM Danilo Pecher via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hi Rob,
>
> I would start a bit more at the meta level and research how kernels
> work. There are also many sites dealing with OS development (osdev is
> useful search term). It is quite instructive to see the first steps
> that happen after the machine boots (the boot loader mainly). Once
> you've really understood that and perhaps cobbled together your own
> simplistic test OS, you should be well on your way to dive into the
> FreeDOS kernel source.
>
> Cheers, Hippo
>
> On Thu, 30 Nov 2023 at 01:02, robert roper via Freedos-devel
>  wrote:
> >
> > Is there a FreeDOS walk thru of the source code that you would consider
> helpful to the uninitiated?  I want to start down the road to more bare
> metal coding and would love to be able to help with FreeDOS in the far
> future but I'm not sure where to begin.  I do know how to program in C and
> have just purchased some old 8086 assembly books to start learning that but
> none of them talk about operating system concepts.
> > I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds
> perfect, except it was published in 1996.  Is there anything like this that
> is more current?  Or do you consider that the definitive guide?
> >
> > Thanks for any help you can provide and apologies if I've sent this to
> the wrong group.
> >
> > Rob
> >
> >
> >
> >
> > _______
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Source

[Danilo Pecher via Freedos-devel]

Hi Rob,

I would start a bit more at the meta level and research how kernels
work. There are also many sites dealing with OS development (osdev is
useful search term). It is quite instructive to see the first steps
that happen after the machine boots (the boot loader mainly). Once
you've really understood that and perhaps cobbled together your own
simplistic test OS, you should be well on your way to dive into the
FreeDOS kernel source.

Cheers, Hippo

On Thu, 30 Nov 2023 at 01:02, robert roper via Freedos-devel
 wrote:
>
> Is there a FreeDOS walk thru of the source code that you would consider 
> helpful to the uninitiated?  I want to start down the road to more bare metal 
> coding and would love to be able to help with FreeDOS in the far future but 
> I'm not sure where to begin.  I do know how to program in C and have just 
> purchased some old 8086 assembly books to start learning that but none of 
> them talk about operating system concepts.
> I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds 
> perfect, except it was published in 1996.  Is there anything like this that 
> is more current?  Or do you consider that the definitive guide?
>
> Thanks for any help you can provide and apologies if I've sent this to the 
> wrong group.
>
> Rob
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS Source

[robert roper via Freedos-devel]

Is there a FreeDOS walk thru of the source code that you would consider
helpful to the uninitiated?  I want to start down the road to more bare
metal coding and would love to be able to help with FreeDOS in the far
future but I'm not sure where to begin.  I do know how to program in C and
have just purchased some old 8086 assembly books to start learning that but
none of them talk about operating system concepts.
I did find a book called "FreeDOS Kernel" by Pat Villani, which sounds
perfect, except it was published in 1996.  Is there anything like this that
is more current?  Or do you consider that the definitive guide?

Thanks for any help you can provide and apologies if I've sent this to the
wrong group.

Rob
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Eric Auer via Freedos-devel]

Hi everybody,

now I have also received one of those freedos phishing mails:
test at multicenter.com.bo wrote "Re: [Freedos-devel] mode.com"
from 193.201.8.100 saying: Please review and sign the enclosed
document. This is essential for our current project (etc.)

The link in the mail interestingly was a doubleclick forward
to a bitly link. Luckily, bitly offers a link preview and
virustotal helped me to find out more. The link had checked
out as harmless 13 days ago, but a "reanalyze" now tells me:

https://www.virustotal.com/gui/url/ff13f15b868cc0b4efdb580f44b621d8f435b82e4fbb6e6fe1cef9327d3fb441/detection

Malware (ESET, Lumu, SOCRadar, VIPRE)
Malicious (Seclookup)
Phishing (Fortinet)

Details about the type of malware are not provided, though.

It is interesting that the previous check was around the
beginning of this phishing or malware wave. Maybe those
sending the mails themselves had their now-infected sites
checked before infecting them, for a fake sense of security?

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Wilhelm Spiegl via Freedos-devel]

Hi Ralf,

yes you are right. I noticed all this before (except the link itself because Android devices use no mouse and the link is not shown in that app). Nevertheless - at the end curiosity won.

And I am not the first one and will not be the last one where this happens.

Since I retired I got at least two phone calls from a "Microsoft technician", several Whats App posts: Hi mum/dad I have a new mobile phone number, some messages

of young ladies, the persons that wants to give me millions of dollars and several other phone attack trials (at least not yet a "shock call from police" that my nephew had an accident and i have to pay money to get him free - this shock call still works fine every day although everyone is warned and bank companies ask their customer when they want a bigger amount of money).

 

I do not know if there were reports in USA that M$ lost one of its main access keys for the whole MS cloud some months ago - and did not really publish this (I am not happy to be forced to use OneDrive etc.)

Big companies are hacked here every day. Etc.  means: I am not alone. Some day they will get you too. There are so many different tricks...

And even if YOU are perfect, others are not. Keep in mind that you have left your email address, paypal account or whatever at douzen of websites,

and some day they can / will be hacked as the admin forgot to run the last updates...

 

Just for info: I checked my Android with 5 different virus scanners, four say: there is nothing, the fifth (VirusTotal) reports that TrendMicro-HouseCall found several of them. One of the four other Virus scanner apps is TrendMicro... So much about this theme.

 

Willi

 
>As for the way how this email is made, well, that is as stated before what makes me wonder on how someone can just click on such a link. "One way link" just doesn't >make any sense in the overall "picture" of the email. So first thing I do before I would even attempt to hover over the link with the mouse, which in my email client will >show me the actual address that link points to. At latest at this point, together with the overall indescriptive  email (not counting the apparently badly copied contents of >an half year old email thread), it should be obvious that this is a phishing attempt.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Phishing attack - warning!

[Ralf Quint via Freedos-devel]

On 11/3/2023 11:36 AM, Wilhelm Spiegl via Freedos-devel wrote:

Hi Ralf,
you never make a mistake? Then you never make a "backup"?

Rarely. And I do.
The thing that is more interesting for me is how the person really 
made it.


I just found this very same email in my spam folder, Thunderbird (or 
GMail) just perfectly fine determined that this is spam, hence, I did 
not see this when it came in.


I certainly won't make the mistake of reading/receiving email in a web 
browser. Email clients exist for a reason, and proper spam/virus 
scanning/filtering is one of the benefits that every email client worth 
it's salt provides.


As for the way how this email is made, well, that is as stated before 
what makes me wonder on how someone can just click on such a link. "One 
way link" just doesn't make any sense in the overall "picture" of the 
email. So first thing I do before I would even attempt to hover over the 
link with the mouse, which in my email client will show me the actual 
address that link points to. At latest at this point, together with the 
overall indescriptive email (not counting the apparently badly copied 
contents of an half year old email thread), it should be obvious that 
this is a phishing attempt.



Sorry Wilhelm, but it's the year 2023 and everyone should know by now 
that the Internet isn't the friendly place anymore it was +30 years ago 
and use common sense



Ralf

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel