Hallo Herr Travis Siegel,
am Donnerstag, 10. Februar 2022 um 13:15 schrieben Sie:
> https://forums.raspberrypi.com/viewtopic.php?t=234228
even if true, here is the wrong place to discuss.
just in case you didn't notice: this here is a forum about FreeDOS,
possibly other DOS in general, but
https://forums.raspberrypi.com/viewtopic.php?t=234228
is a nice summary of the (current) state of affairs with the pi.
It seems things have changed since it's first introduction. I seem to
recall they initially even had a bill of materials listed on their
site. so you could build your own
On Wed, 9 Feb 2022 at 14:17, Travis Siegel wrote:
>
> For what it's worth, the raspberry pi is an opensource board. That means
> you could easily build your own pi using components from the original, and
> have a company produce the board for you.
I think it's important to point out that this
Gentlemen thanks for sharing your thoughts, and for suggesting to
"make one's own hardware" as a solution.
The explanation about the nature of the RPi ecosystem (forking the
hardware being encouraged by the RPi foundation) was particularly
interesting to me.
That said, in my everyday reality,
> For what it's worth, the raspberry pi is an opensource board. That
> means you could easily build your own pi using components from the
> original, and have a company produce the board for you.
As he was intimating, in an industrial environment there are many more factors
to consider than
For what it's worth, the raspberry pi is an opensource board. That means
you could easily build your own pi using components from the original, and
have a company produce the board for you. These days, that's really not
all that expensive, since there's so many hobbiest creating home grown
On 8 Feb 2022 at 23:03, Eric Auer wrote:
>
> How about a Linux with proper RT config and drivers,
> maybe even on a Raspberry-style computer to do I/O
> with that ancient A/D converter hardware? ;-)
>
> Depending on how many channels you need, you could
> also try something like Red Pitaya:
>
>
Hi!
handful of DOS-based control PC's with obscure I/O hardware
(fast-paced low-latency 16bit DC-referenced analog input), and an
amazing but abandoned/unmaintained/closed-source modular
multi-tasking real-time control system (1 ms scheduler clock)
How about a Linux with proper RT config
I don't know how much you're willing to rewrite your program, or how much
you're willing to make fundamental changes to how it works since it may corrupt
what you've already done, but this solution may be worth a shot. I'm doing
something similar in some of my other programs (not related to
Hi there,
On Mon, 7 Feb 2022, Michael Brutman wrote:
... This really isn't relevant to FreeDOS.
I guess clutching at straws I was hoping that the FreeDOS community
might be able to say "Oh, you need Joe's Interrupt Router at http://...;
I have no wish to offend, so I'm out of here now
On 7 Feb 2022 at 21:58, Michael Brutman wrote:
>
> This has all been terribly interesting, but I can't help but think:
> * This product should have been ported to a more capable operating
> system years ago.
> * The inner workings of how the product was made to run under DOS seems
>
This has all been terribly interesting, but I can't help but think:
- This product should have been ported to a more capable operating
system years ago.
- The inner workings of how the product was made to run under DOS seems
to have rotted away.
- This really isn't relevant to
On 8 Feb 2022 at 0:17, G.W. Haywood via Freedos-user wrote:
> Just a quick 'thank you'.
>
entirely welcome... I'm always happy if my superficial scribbling
helps someone.
> Yeah, sorry, I realized that after I hit 'ctrl-X' (that's what passes
> for clicking 'send' on my mail client, which
Hi Frank,
Just a quick 'thank you'. I've speed-read your message and there's a
*lot* of interest in there. I'm very grateful for all the input.
On Mon, 7 Feb 2022, Frantisek Rysanek wrote:
On 6 Feb 2022 at 11:25, G.W. Haywood via Freedos-user wrote:
Did I miss something? No attachment,
Dear Mr. Haywood,
thanks for all the praise... of the two of us, you are the veteran
and the teacher. I just happen to be spending too much time trying to
troubleshoot various random bugs in PC HW+SW, trying to devise a
problem reproduction method, maybe point to a root cause, and ask the
Hi Frank,
On Sun, 6 Feb 2022, Frantisek Rysanek wrote:
On 6 Feb 2022 at 16:24, G.W. Haywood via Freedos-user wrote:
On Sun, 6 Feb 2022, Eric Auer wrote:
A quick thought... Given how fast modern CPU are relative to
serial ports, could you just set a periodic timer to poll
the status of all
> as you have a linux version of your program, I wonder why you insist
>> on running on DOS.
> A number of reasons, as I said. The main reasons are not technical.
> Of course something along those lines would be technically feasible,
> but in some cases it isn't an option.
as you don't
On 6 Feb 2022 at 16:24, G.W. Haywood via Freedos-user wrote:
> On Sun, 6 Feb 2022, Eric Auer wrote:
>
> > A quick thought... Given how fast modern CPU are relative to
> > serial ports, could you just set a periodic timer to poll
> > the status of all serial ports in case configuring their
> >
Hi there,
On Sun, 6 Feb 2022, Eric Auer wrote:
A quick thought... Given how fast modern CPU are relative to
serial ports, could you just set a periodic timer to poll
the status of all serial ports in case configuring their
interrupts on PCI is too tricky? And then let the poll
handler invoke
Hi there,
On Sun, 6 Feb 2022, tom ehlert wrote:
as you have a linux version of your program, I wonder why you insist
on running on DOS.
A number of reasons, as I said. The main reasons are not technical.
Of course something along those lines would be technically feasible,
but in some cases
Hi,
as you have a linux version of your program, I wonder why you insist
on running on DOS. just run your program on a dedicated machine, don't
ever connect it to the any net or WLAN, never update it, and you have
the functional equivalent of a DOS machine.
as a bonus, this even avoids problems
Hi!
A quick thought... Given how fast modern CPU are relative to
serial ports, could you just set a periodic timer to poll
the status of all serial ports in case configuring their
interrupts on PCI is too tricky? And then let the poll
handler invoke your serial interrupt handlers when needed?
Hi Frank,
On Sat, 5 Feb 2022, Frantisek Rysanek wrote:
... I had an inkling to implement "simple OR logic" - which is
not the correct way to share edge-triggered interrupts, but if you
have have a way of polling the ports every now and then outside of
the dedicated ISR, you can avoid losing
Hi Frank,
On Sat, 5 Feb 2022, Frantisek Rysanek wrote:
Yes. I recall ...
Crikey, that was above and beyond the call! Thank you very very much
for that astounding effort. I've skimmmed it (it's late here and her
indoors is grumbling) but I'll spend a lot more time on it tomorrow.
I've been
On 5 Feb 2022 at 0:48, G.W. Haywood via Freedos-user wrote:
> As I
> said in my OP I had to modify some of the cards because they couldn't
> share interrupts properly, by cutting traces and inserting switching
> diodes to do the 'wired or' kind of thing.
>
Yes. I recall ISA multiport boards by
Hi there,
On Sat, 5 Feb 2022, Frantisek Rysanek wrote:
Note that PCI boards do not use "well known" port addresses.
...
... e.g. some interesting work by Michael Chourdakis:
https://www.codeproject.com/Articles/894522/The-Low-Level-M3ss-DOS-Multicore-Mode-Interface
Thank you very much for a
Note that PCI boards do not use "well known" port addresses.
PCI devices get their IO/IOMEM/IRQ resources assigned / allocated on
PC startup semi-dynamically.
For instance, the IRQ routing is nowadays described in an ACPI table,
I believe it's called DSDT... Linux can alternatively be asked to
Hi there,
On Fri, 4 Feb 2022, tom ehlert wrote:
expect COM1234 to be located on 0x3f8,2f8,3e8,2e8 (as indicated at 0x40:10)
expect interrupts 3,4,3,4
Yup, That's what I'm using now for ISA cards :(since about 1985).
Sharing the interrupts isn't generally a problem. Data rates are
generally
Hi,
> The multi-port cards I've used in the past have been ISA. I did have
> to modify some of them to share interrupts, but that's always worked
> OK. Of course these won't fit in most recent computers. Multi-port
> PCI cards I've seen handle interrupt and I/O addressing differently
> from the
Hi there,
On Thu, 3 Feb 2022, Frantisek Rysanek wrote:
On 3 Feb 2022 at 16:38, Bret Johnson wrote:
In the traditional PC architecture, there are only 16 IRQs (0-15)
managed by two Programmable Interrupt Controllers (PICs). Intel
developed APIC (Advanced Programmable Interrupt Controller) in
> One small correction here.
>
> Yes, there are 16 IRQ lines, only 9-16 are not generably accessible,
> so the pc or dos or something in hardware (not sure which) uses IRQ
> 2 to reach IRQs 9-16. I was able to trick a couple network cards
> into working for me by using irq 9, but then setting
One small correction here.
Yes, there are 16 IRQ lines, only 9-16 are not generably accessible, so
the pc or dos or something in hardware (not sure which) uses IRQ 2 to
reach IRQs 9-16. I was able to trick a couple network cards into
working for me by using irq 9, but then setting the
Dear gentlemen,
this is my second attempt to post this. I had to remove ZIP
attachments. Turned them into URL's.
---
On 3 Feb 2022 at 16:38, Bret Johnson wrote:
> In the traditional PC architecture, there are only 16 IRQs (0-15)
> managed by two Programmable Interrupt Controllers (PICs). Intel
Hi there,
On Thu, 3 Feb 2022, Mercury Thirteen via Freedos-user wrote:
On Thu, 3 Feb 2022, G.W. Haywood ... wrote:
... comprehensive and reliable documentation and/or tools useful
for the investigation and routing of interrupts for PCI expansion
cards under DOS I'd be most grateful.
Not
Hi there,
Not sure if they'll have quite the information for which you're looking, but
for all my low level programming needs I always turn to
[OSDev](https://wiki.osdev.org/Expanded_Main_Page).
Hope this helps!
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
‐‐‐ Original
> If for example there's a TSR or something which can say route IRQ19 to
> IRQ3 I think that would do for the forseeable future, but I don't even
> know yet if that makes sense.
In the traditional PC architecture, there are only 16 IRQs (0-15) managed by
two Programmable Interrupt Controllers
Hi there,
Sorry to rake up an old thread, it's what I could find in the archives.
If Sourceforge provides a better search tool than what I've seen I'd
be very pleased to know about it. I found this using a Google clone.
On 2018-06-21 Ralf Quint wrote:
... I am currently away from my FreeDOS
@lists.sourceforge.net
Subject: RE: [Freedos-user] Difficulty with serial communications
Ralf,
Anyway, I checked my FreeDOS stuff this weekend and my diagnostic tool is
unfortunately not among the stuff I was able to restore previously. I do know
that I have another computer where
Hi :-) To make some obvious suggestions: The MODE and TERMINAL
tools in the FreeDOS software list should help you to get low
level status of the serial port. They use mostly BIOS and some
functions might use even more low level I/O, so if you have a
form of simulation of a classical RS232 port,
On 6/25/2018 1:14 PM, Schoenfelder, Tim M wrote:
Ralf,
Anyway, I checked my FreeDOS stuff this weekend and my diagnostic tool
is unfortunately not among the stuff I was able to restore previously.
I do know that I have another computer where this is on, but that is
in my storage and as I am
Ralf,
Anyway, I checked my FreeDOS stuff this weekend and my diagnostic tool is
unfortunately not among the stuff I was able to restore previously. I do know
that I have another computer where this is on, but that is in my storage and as
I am in the middle of moving (again), I can't get that
On 6/25/2018 4:34 AM, Schoenfelder, Tim M wrote:
Hi Bob,
Thank you for your reply.
Sorry, the “>” is the DOS prompt.
I pretty much assumed that much...
Anyway, I checked my FreeDOS stuff this weekend and my diagnostic tool
is unfortunately not among the stuff I was able to restore
Hi Bob,
Thank you for your reply.
Sorry, the “>” is the DOS prompt.
Tim
From: Bob Pryor [mailto:jrpryo...@gmail.com]
Sent: Friday, June 22, 2018 10:28 PM
To: Discussion and general questions about FreeDOS.
Subject: Re: [Freedos-user] Difficulty with serial communications
Hi, lurking here
[W
Hi, lurking here
[When I use a CMD window on the windows 10 disk, I “>echo hello > com1”
worked fine. However, I will try different ports on FreeDOS (My DOS
application only supports com1 & com2).]
Don't have W10 handy, so I tried Vista64 Administrative Command Prompt.
>echo hello > com1
The
On 6/21/2018 5:36 PM, Schoenfelder, Tim M wrote:
I am currently away from my FreeDOS programming stuff, I could send
you some diagnostic tool either tomorrow or over the weekend...
Is it a known tool?
To me, yes ;-) I have written it, but haven't used it in years, the
last time to track
From: Ralf Quint [mailto:freedos...@gmail.com]
Sent: Thursday, June 21, 2018 8:23 PM
To: freedos-user@lists.sourceforge.net
Subject: Re: [Freedos-user] Difficulty with serial communications
On 6/21/2018 5:12 PM, Schoenfelder, Tim M wrote:
How are you booting FreeDOS on a UEFI PC in the first
From: Ralf Quint [mailto:freedos...@gmail.com]
Sent: Thursday, June 21, 2018 7:24 PM
To: freedos-user@lists.sourceforge.net
Subject: Re: [Freedos-user] Difficulty with serial communications
On 6/21/2018 3:45 PM, Schoenfelder, Tim M wrote:
Good point, this appears to be the crux of my issue
On 6/21/2018 3:45 PM, Schoenfelder, Tim M wrote:
Good point, this appears to be the crux of my issue.
Any suggestions/ideas as how to do this? Based on your reply, one
would expect that a TSR or similar is required to handle this if the
UEFI cannot be configured directly to do so.
I did
-Original Message-
From: dmccunney [mailto:dennis.mccun...@gmail.com]
Sent: Thursday, June 21, 2018 6:11 PM
To: Discussion and general questions about FreeDOS.
Subject: Re: [Freedos-user] Difficulty with serial communications
On Thu, Jun 21, 2018 at 5:04 PM, Schoenfelder, Tim M
wrote
upts to the standard DOS
interrupt values which still didn't work.
Tim
From: Ralf Quint [mailto:freedos...@gmail.com]
Sent: Thursday, June 21, 2018 5:53 PM
To: freedos-user@lists.sourceforge.net
Subject: Re: [Freedos-user] Difficulty with serial communications
On 6/21/2018 2:04 PM, Schoenfelder, T
On Thu, Jun 21, 2018 at 5:04 PM, Schoenfelder, Tim M
wrote:
> I am having difficulty getting serial communications to work on FreeDOS 1.2
> using new style PCs such as HPs, Dells, etc. The software fails to
> communicate. To test, I have attempted to use:
>
> ">echo hello > com1"
Out of
On 6/21/2018 2:04 PM, Schoenfelder, Tim M wrote:
I am having difficulty getting serial communications to work on
FreeDOS 1.2 using new style PCs such as HPs, Dells, etc. The software
fails to communicate. To test, I have attempted to use:
">echo hello > com1"
to verify that serial
52 matches
Mail list logo
