subject:"\[Freedos\-user\] Difficulty with serial communications"

Re: [Freedos-user] Difficulty with serial communications

2022-02-10 Thread tom ehlert

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 definitively not about Raspberry PI.

can we please stop this thread.

Tom



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-10 Thread Travis Siegel

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 pi boards. I didn't expect the boot
loader to be opensource, (few companies offer that), though to be fair,
Parallax does with their propeller boards, but those can't run dos,
though they have versions of CP/M that will run on them. I have seen
posts from the raspberry foundation talking about some of the projects
folks have built using the pi, and they even mention such projects in
their newsletters from time to time, so I doubt they're completely
against folks rolling their own hardware. When I got my first pi (the
pi1), I'm almost positive there was a BOM for download on the site, but
I've not looked for it since, having no interest in making my own.

On the other hand, building boards with pi inspired hardware has been
done many times.

The schematics and the board layout are readily available, so anyone can
build a pi themselves as long as they use the commercially available
parts, but honestly, if you're just looking to incorporate the pi into
an existing project, there's nothing preventing you from doing that as
far as I can tell.

Perhaps I was off the mark a bit in stating the entire system is
opensource, but it certainly does use opensource software, and finding
projects where folks used the pi as bare metal isn't difficult either,
so it depends on how much control you want over the final hardware
selection as to whether it will suit your purposes or not.

I apologize for the blanket statement of opensource about the pi,
apparently, that isn't true, but there's enough opensource components
that it's really not a problem in most cases to adapt it to your own
purposes.

I have seen projects where folks built their own boards including pi
components, but perhaps they didn't build a full blown pi, I didn't check.

There's thousands and thousands of projects out there, with some
judicial searching, you're likely to find something close to just about
anything you want to build using a pi.

Unfortunately though, dos won't run on it, so I guess it won't help in
this case.

On 2/10/2022 5:50 AM, Liam Proven wrote:

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 is *only* true of the
very low-end Raspberry Pi Pico, with the RP2040 SOC.

It is *not* true of the RasPi 1, 2, 3, 4, any model of the Pi Zero or
any model of Pi Compute Module.

_Some_ of the Broadcom SOCs from some of the other Pi models have been
available, sometimes, but only in industrial quantities of from 50K to
200K units. You can't buy 1, or 10, or 100.

Secondly, the software is not FOSS either.

The main processor is not the ARM. They are a GPU with an additional
ARM bolted on. The GPU runs the proprietary, closed-source ThreadX
realtime OS, now owned by Microsoft, and not available on the open
market. This means that the RPi firmware is not FOSS and never will
be.
https://en.wikipedia.org/wiki/ThreadX

The GPU device drivers are not fully FOSS either.

There are efforts to built totally FOSS GPU drivers but they are not
complete yet:
https://www.zdnet.com/article/raspberry-pi-4-higher-quality-faster-graphics-edge-closer-with-vulkan-support-via-mesa/

E.g.
https://github.com/Yours3lf/rpi-vk-driver

For the current hardware only part of the functionality of some of the
drivers is FOSS:
https://forums.raspberrypi.com/viewtopic.php?t=326882

Only the ARM part of the OS is FOSS, and you can't load it without
proprietary firmware. The GPU starts first, and it needs ThreadX; then
it loads the ARM OS from µSD (or USB or LAN) into RAM and starts the
ARM.

For the first 5+ years, Linux was also useless without proprietary
drivers: no Wifi™, no Bluetooth™, no graphics acceleration, etc.

There was an attempt to reverse-engineer and build open-source
firmware, but it didn't get far and halted some years ago:
https://github.com/christinaa/rpi-open-firmware

The Pico is a very low-end device, aimed at replacing microcontrollers:
https://www.raspberrypi.com/products/raspberry-pi-pico/specifications/

133MHz CPU, 264 kB of RAM.

This is lower than a mid-1990s specification. It is not and never will
be a general-purpose computer.

TL;DR – Travis' statement is not true in any way for the
generally-available mass-market Pis.

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

Re: [Freedos-user] Difficulty with serial communications

2022-02-10 Thread Liam Proven

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 is *only* true of the
very low-end Raspberry Pi Pico, with the RP2040 SOC.

It is *not* true of the RasPi 1, 2, 3, 4, any model of the Pi Zero or
any model of Pi Compute Module.

_Some_ of the Broadcom SOCs from some of the other Pi models have been
available, sometimes, but only in industrial quantities of from 50K to
200K units. You can't buy 1, or 10, or 100.

Secondly, the software is not FOSS either.

The GPU device drivers are not fully FOSS either.

E.g.
https://github.com/Yours3lf/rpi-vk-driver

For the current hardware only part of the functionality of some of the
drivers is FOSS:
https://forums.raspberrypi.com/viewtopic.php?t=326882

For the first 5+ years, Linux was also useless without proprietary
drivers: no Wifi™, no Bluetooth™, no graphics acceleration, etc.

There was an attempt to reverse-engineer and build open-source
firmware, but it didn't get far and halted some years ago:
https://github.com/christinaa/rpi-open-firmware

The Pico is a very low-end device, aimed at replacing microcontrollers:
https://www.raspberrypi.com/products/raspberry-pi-pico/specifications/

133MHz CPU, 264 kB of RAM.

This is lower than a mid-1990s specification. It is not and never will
be a general-purpose computer.

TL;DR – Travis' statement is not true in any way for the
generally-available mass-market Pis.

--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

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

Re: [Freedos-user] Difficulty with serial communications

2022-02-09 Thread Frantisek Rysanek

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, the integrators and customers of 
various sorts would probably refrain from making their own 
motherboards. The more adventurous types make connector adaptor 
boards or that sort of simple stuff - but make a motherboard? Oh 
no... Regardless of how relatively easy it is, nowadays, to have 
PCB's etched and assembled, making your own motherboard is still 
considered "something for the other end of the supply chain".
I myself have used allpcb.com on several occasions for some 
relatively crude gadgets - but routing a DDR3 bus or decoupling the 
power rails to a GHz-level CPU, no thanks :-)
Have a motherboard designed by someone who's got the know-how. 
Mkay... :-)
Make a custom carrier board for a COM-ETX or Q7, that sounds more 
plausible, because the high density and high speed stuff is confined 
to the CPU module that gets purchased whole, from a motherboard 
vendor.

Unless you're seasoned in the business, PCB-level HW design takes 
several iterations before you get things right. Especially for 
industrial use. And it doesn't even have to be a "difficult 
environment" (dust, Ex, passive, difficult EMI etc). Making things 
all passive with a CPU that consumes 5-10W is not that difficult. 
Avoiding "routing typoes" in the various aspects (EMC, thermals, 
circuit stability) is probably the part that's difficult. Im saying 
this based on various design glitches that I encounter while 
troubleshooting the hardware that we sell...

I know... a nitpicker is the one who's not willing. Who's motivated, 
looks for ways towards the goal...

I applaud Kunbus for going all the way with their industrial 
Revolution PI. In the context of market segmentation, they're in the 
right place: they are a vendor of PLC-style hardware, supplying the 
broad market, and therefore they make their own motherboards.
The R costs are spread over a broad customer base.
Pulling off something at that level for a one-off project sounds moot 
on several fronts: in terms of the business model, the development 
process, possible lead times...

BTW, regarding USB, the first difference is in the transfer rate: 100 
kbps vs. 1.5/12/480 Mbps for USB 2.0. And, USB1/1.1/2.0 is using a 
mixed signaling style, with pull-down and pull-up resistors for early 
slow handshaking, and with half-duplex operation on a single signal 
pair for data. All in all, USB especially 2.0 is far from easy to 
isolate.

Frank



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-09 Thread Bret Johnson

> 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 "producing a board".  In industrial environments you need to 
worry about all kinds of environmental things: EMI/RFI, power fluctuations, 
vibration, shock, temperature, dust, chemicals, volatility, etc.  E.g, in some 
environments you aren't allowed to use any type of fans for cooling or the air 
has "contaminants" (like natural gas or grain dust) which makes it potentially 
explosive so the equipment must never generate any sparks.  In addition, the 
systems must be highly reliable -- running 24x7x365 with no crashes or reboots 
or software upgrades needed.  "Hobby-quality" devices simply won't work.

> On the other hand, I wasn't aware USB had so many issues in noisy
> environments, since they're essentially fast serial ports, I'd
> expect them to be the same as regular serial ports ...

Uh, no.  Even though both they both have the word "serial" in them, USB and 
RS-232 are not even remotely the same thing.  Going back to the environmental 
issues above, I know some USB implementations that have used the USB 
software/protocols but use completely different kinds of cabling and connectors 
which are far more robust than the standard USB hardware.  Of course, that is 
then custom, not compliant with the USB standards, and not necessarily a viable 
long-term solution.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-09 Thread Travis Siegel

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 
boards.  You could easily get a company to produce your circuit boards for 
under a hundred bucks, (sometimes considerably less), even for just a few 
boards.  Roll it into the cost of maintenance, (or initial sales), and the 
boards are paid for fairly quickly.
The whole reason the pi is opensource is exactly for that reason, they 
actively urge folks to tinker and modify the boards to fit their own 
purposes.  Of course, there's other boards that could be used too, but 
most of those would require a programming alteration/shift in tools, os 
those probably wouldn't work for you.  On the other hand, I wasn't aware 
USB had so many issues in noisy environments, since they're essentially 
fast serial ports, I'd expect them to be the same as regular serial ports, 
but I guess faster data rates means less tollerance, so makes sense now 
that it's mentioned, but there's probably no reason standard serial ports 
couldn't be included if you roll your own board.
It certainly takes time invested in board design, and lead times on 
manufacturing of the boards would need to be taken into account, but it 
sounds like your entrenched already, so having a few extra boards on hand 
should be all that's necessary at any given time.
Unfortunately, dos won't run on a pi without an emulator, which adds 
another layer of complexity, but I've never found an affordable intel 
based SBC that I could use to build a usable dos environment from, though 
I have been trying to keep an eye out for such a board.  I suppose if you 
could emulate interrupts, you could program something similar on a pi, but 
I've never seen a project of that sort, so don't know how well it would 
work.
But, if it's just hardware preventing you from switching to a pi, you 
should know there's no issue there, you're welcome to hack the pi design 
to your hearts desire, and even sell said designs, the pi foundation likes 
seeing how pis are being used in the wild.





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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Frantisek Rysanek

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:
> 
> https://redpitaya.com/
> 
> Some USB scopes also support 16 bit modes at low
> sampling rates, with data streaming. But I guess
> you need real-time reaction and USB is evil :-)
> 
> Given that Bret has this "use RTC IRQ at 1024 Hz to
> sort of poll those un-IRQ-able events by hand", you
> may assume that 1 ms scheduler clock is not horribly
> hard with GHz CPU clocks even on Raspberry et al.
> 
> Depending on the hardware, FreeRTOS might help, too.
> 
> Cheers, Eric
> 
Hello Eric,

thanks for chiming in...

Yes I know all that, I've even played with RTAI a little, years ago, 
that's where I learned how to mask SMI sources for instance... if 
memory serves, I was able to service an IRQ at up to 5 or 10 kHz if 
there was not much to do within the handler.

USB per se... I wouldn't be so concerned about the timing delays 
(I've learned that the system need not respond within one scheduler 
cycle of 1ms), but IME, USB is a pig for "industrial control" for 
other reasons, more mundane: the bus is not galvanically isolated and 
only any good for the shortest interconnects (susceptible to EMI), 
sensitive to cabling quality, sensitive to power inrush spikes (in 
DC-powered systems with a switch in the DC rail), in my practice even 
the "port soft-reset" is not very reliable... some of the woes boil 
down to the fact that the USB ports are implemented in the 
chipset/SoC and don't use line transceiver chips / level shifters 
(compared to serial lines for instance). In the wild practical 
environment, USB is "fragile". Troubleshooting USB-related glitches 
in "iindustrial" deployments is almost my daiy business :-(

Speaking of RPi, the vanilla RPi is somewhat popular and there's a 
chance that the product would be available for some time... but its 
"form factor" is woefully inadequate for industrial use. There's a 
German company that's used the open source basis of the RPi and has 
built a product line of PLC-style machines on top of that
https://revolutionpi.com/revolution-pi-series/
and they seem to have a nice analog input module:
https://revolutionpi.com/analog-io-module/

On the scale between "obscure and vendor-locked" vs. an open 
solution, guess where I place this... How future-proof is this.
Maybe if all the software was made to be source-level platform 
independent and portable e.g. between ARM/x86/RISC-V, there would be 
some assurance of future maintainability...

Red Pitaya is a wonderful piece of hardware, but again, on the scale 
of vendor-lock and obscurity vs. future-proofness... ahh well.

My direction of thinking is more in the way of "if this was based on 
the PC and Linux, and I/O interfaces in the form of PCI(-e) boards, 
and the project maintainers would pay attention to having at least 
two I/O board models of each "class" available as products, with 
drivers ready and working with the "control framework", with the 
wiring harnesses solved, that's what might be called a future-proof 
solution.

Of all the operating systems on the market today, including various 
free and commercial RTOS, only Linux appears to always have drivers 
for recent hardware (motherboards and CPU's) and have a somewhat 
assured maintenance. Obviously any future prospect is just my 
subjective guess, based on the status quo of the past two decades.
Perhaps the project wouldn't even need hard realtime (RTAI or some 
such), perhaps a fast-paced timer interrupt (or even just the system 
scheduler tick at 1 kHz) with a high-priority thread would do the 
job. That, while paying attention that the timing-critical box is not 
distracted by other loads.

Regarding long-term HW availability, a different approach might be: 
decide on the solution, develop it, have a target "scale of 
deployment", have it running for a few years to get stats on HW 
failure rates, and before EOL, purchase enough hardware as spares - I 
wouldn't be afraid to suggest 2x the volume of hardware in production 
deployment at target scale. Based on past experience from this 
particular project.

In terms of man-hours required to develop a software framework for 
process control like that, my idea is like a year of a dedicated 
coder's time, for basic functionality, not speaking about nice 
"integrator-level programming interfaces". It takes years of human 
developer time to build a plausible SCADA system...

A single guy doing the coding, and all the hardware integration?
Ahh... no way in just one year, I would say.
It would take a team, working over several years.
For long-term sustainability and maintenance, preferably a team of 
two people who would be "mutually replaceable".

And the freetard in me suggests that a good way to have a chance of 
someone

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Eric Auer




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 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:

https://redpitaya.com/

Some USB scopes also support 16 bit modes at low
sampling rates, with data streaming. But I guess
you need real-time reaction and USB is evil :-)

Given that Bret has this "use RTC IRQ at 1024 Hz to
sort of poll those un-IRQ-able events by hand", you
may assume that 1 ms scheduler clock is not horribly
hard with GHz CPU clocks even on Raspberry et al.

Depending on the hardware, FreeRTOS might help, too.

Cheers, Eric



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Bret Johnson

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 serial ports).  
This is sort of a variation of what Eric suggested earlier in the thread, but 
instead of constant polling it is still interrupt driven so it does not consume 
the entire CPU like a constant polling loop would do.

Instead of relying on the normal serial port IRQs, just disable those IRQs 
altogether.  Instead, setup and use INT 70h/IRQ 8 to generate IRQ's at 1024 Hz 
(you can even set them up to go faster or slower than 1024 Hz, but that may not 
be necessary).  When you receive the IRQ, gather ALL the data from ALL the I/O 
ports you care about (all the serial ports).  Particularly if your serial ports 
are the newer ones that have some sort of internal buffer (more than one byte 
like the original serial ports had) I don't think you'd ever miss any data.

To speed up the processing even more, instead of completely processing the data 
as soon as you received it you could just store the data received in some sort 
of buffer and process it outside of the IRQ handler (or at least after you had 
issued the End-Of-Interrupt for IRQ 8 so you're not "hanging" the machine).

That would avoid all the issues with APIC and/or PCI programming, IRQ sharing 
(at least on the serial ports, but you will still potentially need to share IRQ 
8 which is one reason why you shouldn't change the frequency from the default 
of 1024 Hz), etc.  As long as all the serial ports use "regular" I/O ports 
(PIO) instead of MMIO you shouldn't have any issues getting the data.  But, 
there are ways to get the data from MMIO without using DPMI if that is required.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread G.W. Haywood via Freedos-user


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 unless invited back.

Frank, as you suggest let's continue this privately.  I'm going to go
quiet for a couple of days anyway to do some digesting and because of
life in general.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Frantisek Rysanek

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 
> to have rotted away.
>
Sounds like it has been ported. I understand that the point is to 
avoid forklift upgrades of old PC hardware in existing deployments 
= avoid fixing things that work, requiring manpower that possibly 
isn't really there.

One last (I hope) note on this = excuse another life story:

Unrelated to Mr. Haywood, I have this other veteran/retired customer, 
supporting a [misc heavy industry] company of some sort, running a 
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) written 
in Borland Pascal :-O

The management at the [misc heavy industry] company must've seen the 
writing on the wall for well over a decade. Reportedly, the tight 
timing and some other special sauce (fuzzy controllers, 
discontinuous/hysteretic controllers, non-linear noise filtering) is 
so exquisite in the old system that it's darn hard to find anything 
more modern off the shelf that would serve as a replacement. I mean - 
even just a RAD environment for PC-based industrial process control, 
or some brand of PLC's. So apparently the management just leave the 
old system to its moral decay, and the old bard (my integrator 
customer) keeps the system floating by the skin of its teeth. The 
other management-level option would be to hire some (non-existent?) 
talent to rewrite the thing from scratch in some more modern 
environment that would
- meet the RT timing and control requirements
- have the required algorithms / modules, or be extensible enough to  
  allow the integrator to write the missing software blocks
- be architecturally future-proof: the OS and the control software 
  and the hardware IO, all layered / modular / replaceable, and  
  long-term available.
- the [misc heavy industry] company should demand source code.

I know about various RTOS brands, and Linux with RT extensions, or 
even just vanilla Linux on appropriate hardware, with appropriate 
config (and application SW architecture). Apart from the programming 
effort required, relatively the most difficult part is getting 
industrial-grade analog input with open-source drivers (or 
register-level documentation) - yes there are analog input PCI(-e) 
cards, but the industry has moved away from open HW docs to 
closed-source drivers for the current issue of operating systems. The 
PCI(-e) bus interface on modern industrial IO cards is a custom 
FPGA-based job.
I also know about PC-based and other HW available from National 
Instruments - some of it embedded and dedicated to RT control. NI are 
a powerful and lasting brand, but to me the jury is out, to what 
extent such a solution would be future-proof across proprietary 
platform EOL's and whatnot.

I expect my veteran integrator customer guy to go away one day, and 
the frantic management of the [misc heavy industry] company to come 
hammering on me to revive their system - of which I barely know the 
PC hardware, have disgust for their dependence on every last byte of 
UMB+HMA, have seen a glimpse of the ancient Pascal-based software, 
but have no knowledge of the control-level configuration etc, and no 
spare parts anymore (compatible CPU boards, analog input boards, 
signal conditioning barriers etc).
It's gonna be interesting when the * finally hits the fan.

> *   This really isn't relevant to FreeDOS.
> 
you're right... apologies.

Mr. Haywood I suggest that we move our debate into private e-mail. 
Mine should be visible in my messages.

Frank

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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Michael Brutman

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 FreeDOS.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-08 Thread Frantisek Rysanek

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 doesn't use a mouse... :).
> 
mmm... Pine?
Fond memories of my first jobs and perhaps some courses at school...

I have recently installed (al)pine on a Linux machine where I needed 
local "administrator access" to some IMAP mailboxes that are 
read-only to their nominal IMAP users...

> > ... I'm wondering if your extender uses or produces DPMI, or
> > possibly predates DPMI in the flow of evolution... 
> 
...
> > ... DJGPP compiler ...
> 
> Through all this I've been wondering about the compiler.  The one I
> use for DOS is still the one I bought from Zortech, before they got
> taken over by Symantec.  Imagine that, buying a compiler!  Apparently
> I ran into dozens of issues, and eventually worked through or around
> them all, but if I find myself using new libraries or a different DOS
> extender just to get PCI interrupts working I might not be able to
> build everything with the old compiler.  Scary.
> 
You don't have to explain that to me.
The very essentials of the standard C library library might be 
somewhat portable, but there's the old DOS environment with its 
specific ways, specifics of the ancient compiler+libc, specifics of 
the extender.
No way you'd try to port that to something more modern still in DOS, 
just to add improvised support for PCI-based plain UART's, while 
they're still available...
Not in the context of the production deployment that you've explained 
the last time around.

I mentioned DJGPP+CWSDPMI merely to "decorate my code snippets with 
the related environment they live in".

If all it would take was write a stand-alone real-mode TSR wrapping a 
"trampoline interrupt handler", you could probably get the job done 
with your favourite assembler - and it would probably not be my 
recentish favourite NASM.

I myself am no longer a teenager. Aged 46 I have some coding past 
behind me. And, coding is not even the substance of my day job.  
And I know the feeling when I come back to a piece of code that I 
wrote a decade ago, and I try to re-start the simple "build 
environment" (say just mingw) and I realize that I've changed my 
Windows machine and OS twice in the meantime, that DOS binaries no 
longer run directly in 64bit Windows, and there are other pitfalls 
building 32bit programs in modern 64bit mingw... and reading my own 
code feels like having a deja vu reading someone else's piece :-)
Once, after a long pause from coding in C++, recalling the old quirks 
and corner cases and workarounds felt like I was uprooting a piece of 
nasty weed from my grey matter...
Kind of hard for me to imagine what it's like to return to your own 
creation from 30+ years ago.
I recall my father watching me rummaging in his crate of DIY 
electronics creations in a dusty attic, when I was a kid. He kept 
going like "ohh yes, that was *this* gadget I was trying to build..."
There were some tube-based radioes and cuproxide and selenium 
rectifiers, and some later stuff with discrete Germanium...

Frank

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

Re: [Freedos-user] Difficulty with serial communications

2022-02-07 Thread G.W. Haywood via Freedos-user


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, DKIM says your mail was altered.


I was referring to an attachment in my first message. ...


Yeah, sorry, I realized that after I hit 'ctrl-X' (that's what passes
for clicking 'send' on my mail client, which doesn't use a mouse... :).


... I'm wondering if your extender uses or produces DPMI, or
possibly predates DPMI in the flow of evolution... If it's pre-DPMI,
perhaps it has some service of its own to create the MMIO mapping.
Or does it run in "unreal mode" ? (= no questions asked, you can
access whatever memory address you want)


I'm afraid I've forgotten most of the details, and I fear that the
manuals aren't easily accessible because I've put them in storage in
another country.  I need to look for what I can find online or in my
archives.  I tried to recover an archive over the weekend, but before
it got to anything interesting it filled the disc on my laptop and I
had to stop it.  When I get a chance I'll have another go, this time
being more selective about what's recovered.


http://support.fccps.cz/download/adv/frr/VGA_OFF.zip


Got it thanks, looks very useful.


... DJGPP compiler ...


Through all this I've been wondering about the compiler.  The one I
use for DOS is still the one I bought from Zortech, before they got
taken over by Symantec.  Imagine that, buying a compiler!  Apparently
I ran into dozens of issues, and eventually worked through or around
them all, but if I find myself using new libraries or a different DOS
extender just to get PCI interrupts working I might not be able to
build everything with the old compiler.  Scary.


Apologies for the delays in my responses...


Don't be daft!


And now it's time for me to go to sleep :-)


It's been a long day here too.  Thanks again.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-07 Thread Frantisek Rysanek

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 
vendor for help. My old teenage hobby and habit to read everything 
about x86 register-level programming is just a bit of an aid on this 
job... I don't really have much time for proper programming. Every 
once in a while I manage to code some simple troubleshooting tool.
Unfortunately, messing with the APIC's is not among my past 
"projects" :-(

On 6 Feb 2022 at 11:25, G.W. Haywood via Freedos-user wrote:

> > ... broken BIOS (DSDT) and PCI-e, where turning on "noapic" would
> > result in a combination of "legacy ISA and legacy PCI" IRQ's below
> > 16, combined with MSI used for PCI-e peripherals ...
>
> Urgh.  Looks like I might be writing more pages in my notes.
> 
That was probably too much of an "explanation shortcut" on my part.
The hardware had some "APIC IRQ's" (16-23) misrouted in Linux when 
done via ACPI. There was a stuck peripheral and a different IRQ line 
screaming spurious interrupts. Falling back to the "boot IRQ's" (any 
IRQ's moved under 16 and shared) did work around that ACPI table bug. 
At the same time, Linux was able to use MSI for the several PCI-e 
devices in the system that were actually capable of MSI, thus 
alleviating the IRQ line sharing nightmare. I recall Realtec NIC's 
and some chipset-integrated peripherals ran with the MSI.

> > I've done a bit of googling ...
> 
> I've spent days!
>
Again, the amazement is mine, at your life experince - and your 
willingness to dabble in these tech toys apparently so late in your 
carreer.

> > ... and found some relevant details.
> 
> Sounds like with your experience you might be better placed to pick
> search terms than I am. :/
>
:-) Just a few days ago, on that "mission" troubleshooting a power 
management bug in modern CPU's, after writing some tools of my own, 
and running a diff between two MSR dumps = between a "good" and "bad" 
machine, I googled something like
"bit 1 in MSR_CORE_PERF_LIMIT_REASONS" 
and I got a precise answer. A pointer to a particular Intel erratum. 
That, followed by me banging my head against the wall for a bit - how 
come that Google didn't tell me earlier :-)
Before, while I kept asking about "CPU stuck at low frequency" or 
some such, I got heaps of forum threads where people kept asking the 
same question, receiving typically just superficial answers...
It's just luck in phrasing your questions, and maybe having some very 
specific keywords available.

> > ... Not sure if it's enabled by the BIOS, and thus, if you merely
> > reprogram the IO-APIC to use direct delivery of a particular GSI to
> > the desired IRQ 3 vector, if a corresponding config in the LAPIC is
> > needed: ...
> 
> Well I could just try it. :O
>
Shouldn't be too complicated to test this in a one-off / dedicated 
little program.

Then again... I've tried googling some more, if someone has tried 
messing with the APIC's on his own, and the examples turn out to be 
pretty complex.

https://stackoverflow.com/questions/57373473/
Relevance rating: 60%  (there's lots of text that's uninteresting to 
us)

The following recipe doesn't use APIC's, it's a general demo on how 
to enter protected mode and what to do once you're in:
   https://wiki.osdev.org/User:Johnburger/Demo
It's pretty ancient and it doesn't rely on DPMI, but it does mention 
the IDT and the legacy vector table (IVT)...
Relevance rating: 20%.

Returning to Michael Chourdakis, try reading this from the heading 
"ACPI and APIC":
https://www.codeproject.com/Articles/889245/Deep-inside-CPU-Raw-multicore-programming
That appears to approach the IO-APIC and LAPIC access from a very 
no-nonsense angle - only I suspect it is not the whole story.

Looking into his github repo 
https://github.com/WindowsNT/asm
(I actually downloaded the code to a local hard drive to be able to 
grep) I can see the following track of crumbs to the desired IO APIC 
base address: in file acpi16.asm, look for function DumpMadt .
That's where the IO-APIC base address gets retrieved.
It gets called from a nearby file   code16.asm .
I haven't tried tracking the whole code flow upstream from there, but 
it should give you a recipe on how to get your hands on the IO APIC.
Without engaging a full-blown ACPI table interpreter.

Relevance rating: 80-90% ?

But, I also have a tangential note to make: it turns out that the 
LAPIC (the one baked to the CPU core) has an EOI register = End Of 
Interrupt = the ISR has to ACK this. This means to me that you won't 
be able to simply program an IO-APIC + LAPIC to call the old vector 
for IRQ3 directly - *and be done with it*. You'd probably get a stuck 
IRQ line for your PCI card, because noone would ACK the IRQ to the 
LAPIC :-/

To me, this means "back to square one", as

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread G.W. Haywood via Freedos-user


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 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?


Thanks for the thought.  Frankly I don't know if the performance and
reliability of anything which tried to do it that way could ever be
acceptable but I doubt it.  In any, er, event it would need a lot more
development and testing (which would be prohibitive) than a rewrite of
the interrupt handling code.


Last time I tried, a single inb() or outb() on a parallel 32bit 33
MHz PCI would cost me... not sure if 500 ns is the correct number (or
was it 2 microseconds?)
How often does your dogwatch() routine run?


To the best of my knowledge it never has. :)  The way it would work is
if the terminals all stop responding I get a panic telephone call.  So
I tell the caller to press some combination of keys on the console and
let me know if that fixes it.  That's never happened.


What sort of response time do your terminal users expect? Such as the
echo time when typing characters.
The modern multiport PCI and PCI-e UARTs tend to have large FIFO
buffers, 64B per port or even more = there's hardly a chance of
losing keystrokes if you poll once per second, let alone every 50 ms
or so.


The interrupt-driven bits of code were tested for *years* before being
released and haven't changed for the last quarter of a century, during
which time a number of businesses have used the system from 8am to 6pm
five or six days a week to handle all their sales, some of them turning
over eight-digit sums of money annually.

The only time anyone ever found a mistake, it turned out that the
mistake had been made by someone keeping a manual accounting system
alongside it as a check in the first year.  Nobody does that any more.

I would view switching from interrupts to polling as a fundamental
change in the system.  Knowing what you now know, perhaps you can
imagine how keen I am to make fundamental changes to anything in a
system which is totally relied on and 100% trusted by its users, and
in any case I'm probably not going to live long enough to test such a
major change to my own satisfaction.

Please, let's not wander off the topic.  All I want to do is get an
interrupt to the right place.  A complete redesign of the serial port
handling code instead would be madness.  I don't even want to change
it just to hook a different interrupt, but I will if I have to.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread tom ehlert

> 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 indicate your reasons, or indication why it's not an option:

good luck. and bye.

Tom



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread Frantisek Rysanek

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
> > interrupts on PCI is too tricky? And then let the poll
> > handler invoke your serial interrupt handlers when needed?
> 
> Thanks for the thought.  Frankly I don't know if the performance and
> reliability of anything which tried to do it that way could ever be
> acceptable but I doubt it.  In any, er, event it would need a lot more
> development and testing (which would be prohibitive) than a rewrite of
> the interrupt handling code.
> 
Last time I tried, a single inb() or outb() on a parallel 32bit 33 
MHz PCI would cost me... not sure if 500 ns is the correct number (or 
was it 2 microseconds?)
How often does your dogwatch() routine run?
What sort of response time do your terminal users expect? Such as the 
echo time when typing characters.
The modern multiport PCI and PCI-e UARTs tend to have large FIFO 
buffers, 64B per port or even more = there's hardly a chance of 
losing keystrokes if you poll once per second, let alone every 50 ms 
or so.

Frank


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread G.W. Haywood via Freedos-user


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 your serial interrupt handlers when needed?


Thanks for the thought.  Frankly I don't know if the performance and
reliability of anything which tried to do it that way could ever be
acceptable but I doubt it.  In any, er, event it would need a lot more
development and testing (which would be prohibitive) than a rewrite of
the interrupt handling code.

Unless there's some miracle DOS device driver in the post to me right
now, at this point I think I'm more or less resigned to the rewrite.

As I write I'm pulling the source archives out of mothballs to set up
a build system.  It's years since I built a DOS executable.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread G.W. Haywood via Freedos-user


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 it isn't an option.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread tom ehlert

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 with UEFI-only machines in the
future.


Tom



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread Eric Auer




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?

Regards, Eric



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-06 Thread G.W. Haywood via Freedos-user


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 keystrokes ...


Yup.  A function called dogwatch() which gets called now and again. :)


... broken BIOS (DSDT) and PCI-e, where turning on "noapic" would
result in a combination of "legacy ISA and legacy PCI" IRQ's below
16, combined with MSI used for PCI-e peripherals ...


Urgh.  Looks like I might be writing more pages in my notes.


Which obviously does not help you to re-route a particular APIC GSI
to IRQ3/4, if that's your whole point...


Quite.


I've done a bit of googling ...


I've spent days!


... and found some relevant details.


Sounds like with your experience you might be better placed to pick
search terms than I am. :/


To re-route some particular IRQ line (APIC input) e.g. to IRQ3 or
... two different theoretical possibilities:



A) reprogram the relevant IO-APIC


It seemed to me that this might be the 'proper' way to do it.


B) make a TSR that installs an ISR for the "boot IRQ" ..


That's the way I've been leaning so far.


A) reprogram the relevant IO-APIC
...
... https://wiki.osdev.org/IOAPIC


Thank you.


...
Looking at the IO APIC register map, it's clear that if you know or
can find out the right GSI (row in the table), you can tell the APIC
what *vector* to call ...


The sort of thing I had in my simple mind.


... "legacy mode" is a whole separate arrangement...
... https://groups.google.com/g/linux.kernel/c/0CZSA3ZtToE?pli=1
and I just hope I understand it correctly.


Urgh.


... Not sure if it's enabled by the BIOS, and thus, if you merely
reprogram the IO-APIC to use direct delivery of a particular GSI to
the desired IRQ 3 vector, if a corresponding config in the LAPIC is
needed: ...


Well I could just try it. :O


... DPMI / protected mode have some specific workarounds (a
translation layer) for legacy DOS interrupt services...
... you'll probably need DPMI even to take a look into the APIC.
...


I've been looking around for the source for the DOS extender I used,
it's called X32 from a company called Flashtek which was formed by a
couple of Zortech developers after what I gather was an acrimonious
dispute with Symantec (who bought Zortech, then seemingly welched on
some contract terms).

https://en.wikipedia.org/wiki/DOS_extender

Back in the day I tried several, they all had their shortcomings but
X32 seemed to work better than anything else I could find - plus the
author (a guy called Doug Huffman, who apparently worked on a farm in
Idaho in the summer and on software for a bit of light relief in the
winter) was very responsive - so I stuck with that.  No sign thus far
of any source, but there are other apparently well-regarded extenders
which are open source.  I might give Causeway a spin but (since about
mid-2018) I don't run a large in-house installation of DOS business
software, testing it under real-world conditions presents challenges.


If you'd appreciate further reading ...


Always up for further reading, thanks!


... To me, the complexity of ACPI is sheer and humiliating.
Probably much too complex to try and save old DOS software.


Well it can sometimes work under an emulator or a VM, but I'm
beginning to think you're right about that too.  It would be much
easier if there had only ever been one take on it.


B) software-based rerouting of IRQ's:
...
I've never done this and cannot offer any detailed instructions...
...
Actually, I just seem to have spotted a pitfall: ...


If there's only one I'll be pleasantly surprised. :/


To sum up, I cannot see any easy prospects for "transparent IRQ
redirection". If you have the source code of your production app,
your safest bet is probably just to hook the right IRQ, available to
you transparently by means of the "boot IRQ" mode if your system is
new enough to have an APIC.


As per my first reply to your post, I think you might be right.


BTW, PCISCAN utils have been mentioned...


Got it, I'll take a look.


BTW2, Pascal is not my pot of tea either.


:-}


... PCI-1716 driver that I've included is just an odd experiment ...


Did I miss something?  No attachment, DKIM says your mail was altered.

Thanks very much once again for the education, it's most welcome.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-05 Thread G.W. Haywood via Freedos-user


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 half-thinking I might try tweaking a table somewhere, but it
isn't a long-term option and for sure it won't always work anyway.

I'm beginning to think your punchline might be on the money, just bite
the bullet and hook the IRQ that's offered.

Thanks again!

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-05 Thread Frantisek Rysanek

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 Advantech that had and extra 
"register", implemented by a CPLD, that worked like a 3rd-level PIC.
Not merely a status register with a bitwise flag per UART channel.
Whenever you got an IRQ from such a card, you'd have to ACK to your 
AT-PIC and *then* an extra ACK to that card's own "sharing register". 
It was a way to implement sharing of edge-triggered IRQ's properly. 
And it wasn't very well documented if I recall. Advantech would 
provide its own library which did work, as long as you could link 
that to your software. If you couldn't recompile, bad luck for you. 
The library was pretty small, I recall trying to reverse it with a 
disassembler...
The vendors of such hardware probably protected their "intellectual 
property" that way.
And indeed 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 keystrokes from your 
terminal.

> Yes, I get PCI card addresses/interrupts from 'lspci' on a Linux box.
>
If you try booting with "noapic" and maybe "acpi=off", you should see 
your PCI IRQ's assigned to numbers below 16. I've even seen setups 
with a broken BIOS (DSDT) and PCI-e, where turning on "noapic" would 
result in a combination of "legacy ISA and legacy PCI" IRQ's below 
16, combined with MSI used for PCI-e peripherals that supported that 
:-)

Which obviously does not help you to re-route a particular APIC GSI 
to IRQ3/4, if that's your whole point...

I've done a bit of googling and found some relevant details.

To re-route some particular IRQ line (APIC input) e.g. to IRQ3 or 
rather its ISR vector, I can see two different theoretical 
possibilities:

A) reprogram the relevant IO-APIC 

B) make a TSR that installs an ISR for the "boot IRQ" line (= under 
16) that your PCI board gets from the BIOS, and from that ISR, call 
the original ISR of IRQ3 (or whatever it is that you're trying to 
mimick).

In detail:

A) reprogram the relevant IO-APIC 

Unless you're using server boards, we're realistically we're speaking 
the chipset-integrated IO-APIC. This particular APIC is an on-chip 
part of the south bridge, since about i815. The IO-APIC is a neighbor 
of the AT-PIC (two pieces of the i8259 cascaded) and they have some 
umbilical interconnection - although in fact, I guess any extra 
IO-APIC's integrated in PCI bridges ultimately produce the same 
overall behavior...

First, mind the difference between:

- an IO-APIC = the one that receives the IRQ "wires" from PCI devices 
and passes the IRQ events further, based on how it is programmed.
This is what we'll need to mess with.

- a CPU local APIC = one per core, the receiving end of various sorts 
of interrupts, the one actually arranging the jump to an ISR vector 
on that particular CPU core. Not sure if we need to touch this or 
not.

A modern PC system has both kinds of APIC's, even if there's just a 
single CPU core. The APIC system architecture supports multiple 
cores, and you'll find references to that in all the docs, including 
some elements in the APIC configuration registers. In DOS, all your 
software likely runs on the BSP = "BootStrap Processor", i.e. the 
"default CPU core" that ends up running your DOS when BIOS hands over 
control after POST.

I've found a pretty neat and compact description of what an IO-APIC 
is, at osdev.org - including a register map:
https://wiki.osdev.org/IOAPIC
At the end of that wiki article, there is a link to an Intel MPS spec 
in PDF (already from web-archive) - it contains a block diagram of a 
multi-CPU multi-APIC system, in its original form, with the APIC 
IRQ's being delivered over a dedicated "APIC bus".
Since then, there's been a change, nowadays the APIC IRQ's are 
delivered inband over the system bus (DMI, which is just an 
obfuscated PCI-e) which doesn't have to worry you, as that particular 
detail is transparent to you as a programmer.

Looking at the IO APIC register map, it's clear that if you know or 
can find out the right GSI (row in the table), you can tell the APIC 
what *vector* to call at which CPU, as identified by an APIC ID 
(which is apparently just an ordinal number - the BSP probably has an 
APIC ID = 0).
But, this is not all.

Apparently, the "just after POST" state of IRQ routing, where only 
IRQ's under 16 are used (and heavily shared) is not implemented by 
means of a corresponding configuration of the APIC mapping of the 
GSI's to ISR vectors in CPU cores.
Rather, that "legacy mode" is a whole separate arrangement, where the 
IRQ's are in a so called "boot IRQ mode". Apparently, in this mode, 
the

Re: [Freedos-user] Difficulty with serial communications

2022-02-05 Thread G.W. Haywood via Freedos-user

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 most interesting and illuminating post, I'll
certainly be following up your pointers.

In case you were wondering about running DOS and DOS apps on modern
PC hardware, one of the problems you'd face might be that the CPU's
are too fast for some old software. Unfortunately the Pascal CRT
library (error 200 / division by 0), which is patchable, is not the
only such problem. There are other pieces of software affected ...

To the very best of my knowledge I've never had the problem that a CPU
has been too fast to do something for me! The code I've written makes
absolutley zero assumptions about execution time save that it might be
a while before we get a response to something so we should probably do
something else in the meantime. For DOS systems, the display code and
low-level interrupt routines are written in C plus a bit of assembler.
For Linux the display is via the ncurses library and the system itself
handles all the interrupts of course. No need for me to get involved,
just read and write the pseudofiles. The last time I seriously used a
Pascal compiler (well, tried to) was in the late 1970s, when I was the
Technical Director of a firm making instruments for nuclear medicine.
The compiler turned out to be riddled with faults. Last I heard of it
was at Chicago O'Hare airport when I gave an inch-thick printout binder
detailing dozens of faults to the supplier's representative. He took
it away, and as far as I can remember we never heard from them again.
We replaced Pascal with RTL/2 from a company in Oxfordshire, England,
which offered remote debugging via our instruments' serial ports...
Forgive me if you're fond of Pascal, I did rather like the look of it
at the time but back then the implementations seemed a bit patchy.

My display frivolities are limited to drawing boxes using the special
box-drawing characters (approximately a dozen of them) for DOS systems
and direct cursor positioning is about the limit of this folly. Linux
builds use the four ASCII characters '=|-_' instead of the box drawing
characters. It makes the screens a little less aesthetically pleasing
but they otherwise do exactly the same things. People get used to it.

I'm writing all this to introduce my recent "discoveries" allowing
me to underclock modern CPU's, using EIST and CLOCKMOD combined,
down to a fraction of their nominal frequency... Tried on a Core2Duo
and on a Haswell, in DOS. I haven't written a public blogpost on
the topic yet... let me know of you need this.

Thanks very much for the offer, but I can't see that I'd ever want any
CPU I'm using to go slower. In fact quite the reverse!

73,
Ged.

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

Re: [Freedos-user] Difficulty with serial communications

2022-02-04 Thread Frantisek Rysanek

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 
"route the IRQs", not sure how that works.

Multiport ISA boards have always been a pain exactly because of IRQ 
sharing. ISA IRQ's are edge-triggered and not implemented in a way 
that would allow for easy sharing. If your ISR caters for all the 
devices on that line, there's a chance to pull it off (and not get a 
stuck IRQ line). PCI IRQ lines are much easier to use in a shared 
setup.

I've seen modern industrial PC hardware that has maybe 6 to 10 COM 
ports onboard - implemented using two LPC SuperIO chips. In those 
cases, all the COM ports are in the ISA address range.
Still, there's no standard for "well known addresses"
for COM5 and above. You often have a choice in the BIOS of such 
machines - not sure about IO addresses, but definitely a choice of 
IRQ's. Also, even if the BIOS does not allow you to configure those 
IO addresses, these SuperIO COM ports typically have their bases 
configurable in bare hardware - via the SuperIO configuration 
registers. Each COM port is a SuperIO "logical device" and has a base 
address register in the SuperIO config register bank. These are 
accessible via "multiplexed gates", often at 2E+2F or 4E+4F. There's 
always an "unlocking sequence" preventing inadvertent entry - and 
each vendor has a slightly different sequence... it's just a few 
outb's. Datasheets are available. I have some assorted code examples 
if that's relevant.


Very theoretically, with multiport serial PCI cards, it might be 
possible to reprogram the BAR's (by writing the card's PCI config 
space) into the legacy ISA range. But, there are pitfalls.
Apart from writing the BAR in the target device, which supposedly 
already makes the PCI device "decode" that address, you need to be 
lucky enough to have upstream PCI bridges actually deliver the IO 
transactions "your way". You may find out that the whole ISA IO space 
with small exceptions is "routed" to the LPC bridge within the south 
bridge chip, and ends up being decoded by the LPC SuperIO chip(s). 
Actually, rather than an explicit "all ISA" window (IO ports 
0-0x400), the LPC bus may be a "destination of last resort" in 
"subtractive decode". PCI devices normally practice "positive decode" 
and that's how PCI bridges should treat them. Only one "branch" in 
the PCI tree, typically ending in a SuperIO chip, can support 
subtractive decode = become a "sink of last resort" for IO port 
access that's not claimed ("positively decoded") by another device.

My friend Rayer has once mentioned that he'd tried this, and was 
half-way successful... I seem to recall that he managed to re-route 
LPT2 to a PCI card, but not LPT1... or some such.


Regarding the modern IRQ routing style, via IO-APIC's to the per-core 
LAPIC's... Not sure to what extent the legacy AT PIC = cascaded 2x 
i8259 is reproduced in modern PC hardware, as opposed to just 
programming the IO-APIC such that only IRQ lines 0 to 15 are used, 
for their well-known purposes (where such a well-known assignment 
exists). Starting from Intel 8xx series chipsets, probably the i815 
for the later iterations of the Pentium III, every ICH south bridge 
contains an IO-APIC with 24 GSI's (input lines) which get internally 
routed to just the bottom 16 IRQ's for legacy DOS compatibility. It 
takes a more modern OS to start the IO/APIC and unleash its power. Or 
even to switch over to MSI... I've already mentioned the ACPI DSDT.
You probably won't want to include an ACPI table iterpreter in your 
old DOS program :-) Actually, what's fixed in the hardware, is the 
wiring of the IRQ lines on the motherboard - how the PCI IRQ braid is 
woven among the slots and onboard devices, and how it's wired to the 
IO-APIC's GSI pins. From there, internal routing inside the IO-APIC 
is programmable. Given a piece of PC hardware, and if you study the 
APIC programming enough, you might be able to figure out the needed 
routing exercise in bare APIC metal, even without asking the ACPI 
BIOS interface.

If you were interested what it takes to access the APIC, I mean get a 
kick-start / bootstrap, there's e.g. some interesting work by Michael 
Chourdakis:
https://www.codeproject.com/Articles/894522/The-Low-Level-M3ss-DOS-Mul
ticore-Mode-Interface
...the purpose of the project is to show how you can use more than 
one CPU core in DOS, using a simple extender... and I'm pointing to 
it because to start several cores, you need to work with the APIC's, 
so there are some examples in the code where this is used.
Again, note that the source code is heavy in 32bit black magic.


And to close this message, I have a side note:
In case you were wondering about running DOS and DOS apps on modern 
PC hardware, one of the

Re: [Freedos-user] Difficulty with serial communications

2022-02-04 Thread G.W. Haywood via Freedos-user


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 very low - the screens typically run at 9600 bit/s - and
it's rare that all the operators are hammering away at once.


https://de.wikipedia.org/wiki/Interrupt says
3   COM 2, 4, 6, 8 (EIA-232/RS-232)
4   COM 1, 3, 5, 7


Oh, thanks, I hadn't seen that page - it's quite different from the
English version.  I've used 8-port ISA cards which do just that, a few
others which use a single interrupt, and others with jumpers.  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.


for the obvious question where COM5678 have their ports, you have to
consult PCISCAN utilities, or the wider internet...


On the ISA cards that I've used the addresses tend to be 1A0, 1A8,
1B0, 1B8, 2A0, 2A8, 2B0,...  Addresses for the PCI cards I get seem to
be E000, E800...  Again as per the OP they aren't a problem, it's just
the interrupts *not* being IRQ3 and IRQ4 (e.g. IRQ19) which is the
nuisance for me.  I keep seeing references to software or drivers or
whatever which can route e.g. IRQ19 to IRQ3 and that would be perfect
but I haven't found anything that actually does it yet.  I've ordered
Yet Another PCI card which claims to have (I guess) a driver which can
do that, if it really does I'll be both grateful and surprised.


it might be useful to install linux, windows, or whatever on a
machine with such a multi-port adapter...


Yes, I get PCI card addresses/interrupts from 'lspci' on a Linux box.
The cards are no trouble under Linux.  I don't have to do anything for
the interrupt handling, just open /dev/ttyS7 or whatever for I/O.

All this has got me looking back at my notes about this stuff from the
1980s and 1990s and I almost can't believe how much trouble I had to
go to to get it working back then.  Pages and pages of problems with
assemblers, compilers, DOS extenders, libraries, utilities, hardware,
you name it there seem to have been problems with it.  Makes me feel a
bit nostalgic, but very grateful that nowadays almost everything seems
to just plug in and work with none of that hassle.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-04 Thread tom ehlert

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 way the ISA cards did it.  I/O addresses are no problem, any
> address is configurable in the software, but despite claims to be able
> to use IRQ3 and IRQ4 in the sales literature none of the PCI cards
> that I've tried so far appears to be able to use either.

some warnings first: my (extensive) experience with COMx is ~23 years
old, so I may be wrong.

expect COM1234 to be located on 0x3f8,2f8,3e8,2e8  (as indicated at 0x40:10)
expect interrupts 3,4,3,4

https://de.wikipedia.org/wiki/Interrupt says
3   COM 2, 4, 6, 8 (EIA-232/RS-232)
4   COM 1, 3, 5, 7

for the obvious question where COM5678 have their ports, you have to
consult PCISCAN utilities, or the wider internet...

only if that doesn't work, dig deeper.

> My software
> expects that only those will be used for serial comms (if you think
> that means the software is silly, I'd blushingly have to agree).
even in hindsight, I *think* even today only 3 and 4 are used.

it might be useful to install linux, windows, or whatever on a
machine with such a multi-port adapter and use
settings->devices->COM5->properties to investigate this.


> At some point I'd like to modify the software to handle more recent
> hardware but it's a long time since I did all that and I've almost
> forgotten how it all hangs together.
+1

tom



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-04 Thread G.W. Haywood via Freedos-user


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 the
Pentium/multi-processor era (many years ago) ...


I'd say that you do not need to deal with IRQ routing through the
APIC's and serving IRQ's higher than #15.
You do need to talk to the PCI BIOS (int 0x1A) to ...


Thanks to both, for some very useful (and encouraging) feedback.

To all: keep it coming!


Hmm... did you just say that your software can run in Linux too?


Yes, but just because you *can* do something, it doesn't necessarily
follow that you *should*. :)


In that case, why bother to write drivers for DOS ?
New hardware for Linux is probably much cheaper than your time! :-)


The systems I'm supporting are DOS systems.  For a number of reasons
the intention is for them to stay that way.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread Bret Johnson

> 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 software to
> IRQ 2, since it didn't have IRQ 9 as an option.

Yes, there are LOTS of details and complications associated with the IRQs that 
you may need to work around.  The IRQ 2 cascade to the second PIC is one of 
them, but there are also others like some of the IRQs being dedicated (and even 
hard-wired) on the motherboard to certain devices.

If you're going to be messing around with IRQ's, and especially if you're going 
to re-route them, there's a lot more information needed than can be included in 
a simple e-mail.

I think the overall goal here is to have the PCI serial port look like a 
"regular" serial port (probably COM1 or COM2) so the original software doesn't 
need to change.  Exactly how to make that happen is the question.  If the PCI 
card came with some sort of configuration utility it may be fairly easy to do.  
If not, then things get much more complicated.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread Travis Siegel


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 software to IRQ 2, 
since it didn't have IRQ 9 as an option.


I'm not entirely sure how this will help you, but it might be something 
you can try to make things behave for you as well.



On 2/3/2022 11:38 AM, Bret Johnson wrote:

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 (PICs).  Intel developed APIC (Advanced 
Programmable Interrupt Controller) in the Pentium/multi-processor era (many 
years ago), mostly to to address the requirements of multi-processor systems.  
But, APIC also allows you to have more than 16 IRQs in single-processor systems.

APIC requires support both in the hardware/BIOS and in the OS/application.  
I've never seen any sort of DOS implementation that supports APIC, but there 
may be something out there somewhere.  I think what you're trying to do might 
be possible (assuming you have the correct hardware and BIOS support), but is 
going to be very complicated and you're probably going to need to implement it 
yourself.  I don't think you'll find an existing TSR that will do what you want.

You may also just be able to share IRQ 3/4 between several applications.  It is 
possible to share IRQ's if ALL the software is written correctly, but most 
software is written assuming only one program manages each IRQ.


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



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

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread Frantisek Rysanek

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
> developed APIC (Advanced Programmable Interrupt Controller) in the
> Pentium/multi-processor era (many years ago), mostly to to address the
> requirements of multi-processor systems.  But, APIC also allows you to
> have more than 16 IRQs in single-processor systems. 
> 
> APIC requires support both in the hardware/BIOS and in the
> OS/application.  I've never seen any sort of DOS implementation that
> supports APIC, but there may be something out there somewhere.  I
> think what you're trying to do might be possible (assuming you have
> the correct hardware and BIOS support), but is going to be very
> complicated and you're probably going to need to implement it
> yourself.
>
I'd say that you do not need to deal with IRQ routing through the 
APIC's and serving IRQ's higher than #15.
You do need to talk to the PCI BIOS (int 0x1A) to find your device on 

the bus and inquire its PCI config space about:
- the port IO space occupied
- the IOMEM space occupied
- the IRQ allocated.

Yes, if I understand things correctly, your PCI(-e) board does have a 
legacy IRQ# <16 allocated by the BIOS during post, and chances are, 
that if you hook that IRQ number learned from the PCI config space, 
you'll start getting IRQ events. 

Note that PCI IRQ's are level-triggered, for easier sharing. (Your 
IRQ line will likely be shared by several devices.) Which makes me 
believe that you do not need to ACK the interrupts to the old AT-PIC. 
Instead, try just satisfying all the interrupt sources in your UART 
or PCI board - if you succeed, the IRQ line gets de-asserted, and 
your ISR simply won't get re-invoked again right away. If there's 
another device with an IRQ source firing on that shared IRQ line, and 
you haven't handled that one already, your ISR will get called again.

In Linux (not sure about Windows) this is used by the OS: the OS has 
a "super-ISR" per IRQ line, and as a driver writer, you register your 
HW-specific ISR with the OS, and the OS calls all the specific 
registered ISR's for that shared line in a sequence, maybe checking 
for their return values if that matters to the OS.
In DOS, you're on your own. If you want to be polite, and expect 
other people's TSR's to share that IRQ, perhaps you can call the 
"downstream" ISR vector that you've backed up when hooking the IRQ 
yourself...

You'll probably find a pretty good datasheet for the PCI UART chip on 
your addon board. And/or a Linux driver. If some snippets of 
information are missing in the puzzle (the docs are sketchy), with 
simple peripherals you can often get further by looking at the BAR's 
(in Linux using lspci -vvn without even programming) and then you can 
try poking some of the BAR's to see if you get the expected 
responses. A 16C550 backwards-compatible UART is no rocket science, 
and you don't need an IRQ to provoke some activity to the outside 
world.

Port IO is easy - you get the base and range from the respective BAR, 
and you can start poking.

Now if the chip's registers are memory-mapped, that's potentially 
hard cheese.
To access memory-mapped registers in a PCI device, you need to 
perform an "ioremap" operation (maybe you can do without it in unreal 
mode) and the physical and remapped addresses are not likely in the 
DOS conventional memory under 1 MB = you need an OS service to do the 
32bit memory management for you. In Linux and Windows this is a 
boring basic service of the kernel. In DOS, you need DPMI, and you 
probably need to compile your whole project as a 32bit application 
(not sure). In DOS, I can possibly suggest the DJGPP (GCC) + NASM, as 
an environment that I've met before and maybe done some stuff in...

Not sure if Japheth is reading this mailing list, but there are other 
people who can certainly fill in my blanks on this :-)

The PCI BIOS stuff still takes some coding and wrapping to be 
comfortable to use. In my archive, I've found some internal toy 
"projects" of mine, where such wrappers can be obtained. 
I'm including two ZIP files - refused by the list server, get them 
here:
http://support.fccps.cz/download/adv/frr/smi.zip
http://support.fccps.cz/download/adv/frr/pci-1716.zip

The first one is heavily C-centric, including the BIOS calls 
(software interrupt 0x1A).
The other one is Pascal-centric, and the PCI manipulation "unit" is a 
combination of nasm implementation with a Pascal source wrapper 
providing a Borland Pascal "interface".

Namely, to get you inspired, check the PCI-related header file and 
look for macros
PCI_CS_INTERRUPT_LINE
PCI_CS_INTERRUPT_PIN
They're offsets in the per-device window of PCI config space.
You have mentioned Linux... in modern Linux, you'll see your IRQ 
mapped to some high

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread G.W. Haywood via Freedos-user


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 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).


Thanks for the reply!  I'd never seen that site before and it looks
interesting, although some (most?) of the articles I've read so far
are, well, what I think I'd call Spartan rather than comprehensive and
so far I've found it difficult to judge how current/relevant it is.
But I'll definitely be spending more time nosing around in there.

Thanks again.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread Mercury Thirteen via Freedos-user

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 Message ‐‐‐

On Thursday, February 3rd, 2022 at 8:46 AM, G.W. Haywood via Freedos-user 
freedos-user@lists.sourceforge.net wrote:

> 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 programming stuff, I could
>>
>> send you some diagnostic tool either tomorrow or over the weekend ...
>
> My application is a very old suite of business software which I wrote
>
> about 30 years ago and is still in very active use. It's a multi-user
>
> sales/purchases/stock control/ etc. accounting system. It runs under
>
> FreeDOS, MS-DOS and Linux. It can use multiple serial port cards for
>
> the user terminals. The largest DOS installation I've done was eleven
>
> terminals (+console), although most only use one or two. Changes in
>
> legislation in the UK mean that here and there an extra I/O port will
>
> be wanted for what HMRC calls the 'digital link' between the business
>
> software and the desktop stuff which interfaces with HMRC's computers.
>
> 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 way the ISA cards did it. I/O addresses are no problem, any
>
> address is configurable in the software, but despite claims to be able
>
> to use IRQ3 and IRQ4 in the sales literature none of the PCI cards
>
> that I've tried so far appears to be able to use either. My software
>
> expects that only those will be used for serial comms (if you think
>
> that means the software is silly, I'd blushingly have to agree).
>
> At some point I'd like to modify the software to handle more recent
>
> hardware but it's a long time since I did all that and I've almost
>
> forgotten how it all hangs together. 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.
>
> If you (or anyone else) can point me to 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.
>
> ---
>
> 73,
>
> Ged.
>
> Freedos-user mailing list
>
> Freedos-user@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/freedos-user___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread Bret Johnson

> 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 (PICs).  Intel developed APIC (Advanced 
Programmable Interrupt Controller) in the Pentium/multi-processor era (many 
years ago), mostly to to address the requirements of multi-processor systems.  
But, APIC also allows you to have more than 16 IRQs in single-processor systems.

APIC requires support both in the hardware/BIOS and in the OS/application.  
I've never seen any sort of DOS implementation that supports APIC, but there 
may be something out there somewhere.  I think what you're trying to do might 
be possible (assuming you have the correct hardware and BIOS support), but is 
going to be very complicated and you're probably going to need to implement it 
yourself.  I don't think you'll find an existing TSR that will do what you want.

You may also just be able to share IRQ 3/4 between several applications.  It is 
possible to share IRQ's if ALL the software is written correctly, but most 
software is written assuming only one program manages each IRQ.


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

Re: [Freedos-user] Difficulty with serial communications

2022-02-03 Thread G.W. Haywood via Freedos-user


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 programming stuff, I could
send you some diagnostic tool either tomorrow or over the weekend ...


My application is a very old suite of business software which I wrote
about 30 years ago and is still in very active use.  It's a multi-user
sales/purchases/stock control/ etc. accounting system.  It runs under
FreeDOS, MS-DOS and Linux.  It can use multiple serial port cards for
the user terminals.  The largest DOS installation I've done was eleven
terminals (+console), although most only use one or two.  Changes in
legislation in the UK mean that here and there an extra I/O port will
be wanted for what HMRC calls the 'digital link' between the business
software and the desktop stuff which interfaces with HMRC's computers.

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 way the ISA cards did it.  I/O addresses are no problem, any
address is configurable in the software, but despite claims to be able
to use IRQ3 and IRQ4 in the sales literature none of the PCI cards
that I've tried so far appears to be able to use either.  My software
expects that only those will be used for serial comms (if you think
that means the software is silly, I'd blushingly have to agree).

At some point I'd like to modify the software to handle more recent
hardware but it's a long time since I did all that and I've almost
forgotten how it all hangs together.  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.

If you (or anyone else) can point me to 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.

--

73,
Ged.


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

Re: [Freedos-user] Difficulty with serial communications

2018-08-07 Thread Schoenfelder, Tim M

The FreeDOS serial communications is now working on my modern PCs.  The serial 
port was expecting DTR and RTS signals to be asserted.  Once they were 
asserted, it worked.

Thanks to all who responded!

Tim
From: Schoenfelder, Tim M
Sent: Monday, June 25, 2018 4:14 PM
To: freedos-user@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 this is on, but that is in my storage and as 
I am in the middle of moving (again), I can't get that one out for now.

I do however have various pieces of source code from which I can whip up 
another test program. Will do so when I get back home later today/tonight.

If you could put the source(s) onto a github site or similar that I could then 
download and compile, that may be the best way for me to get permission to try 
it here at work. - Tim

The basic issue is that this is less of a problem of (Free)DOS, but what 
exactly the hardware/BIOS is providing and initializing in regards to the 
serial ports.
Yes, your first reply suggested that. I have since started reading the UEFI 
spec ( http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf 
). I hope to understand how to access the serial port in UEFI legacy mode both 
with and without FreeDOS loaded as UEFI’s runtime functions are different than 
its bootload functions. That may help explain why my serial communications 
efforts in FreeDOS presently fail. -Tim

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-27 Thread Eric Auer

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, which will cause
problems for some DOS programs, then MODE and TERMINAL should
also suffer from that ;-) http://www.freedos.org/software/

Regards, Eric

PS: Terminal is "util", mode is "base".


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-26 Thread Ralf Quint


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 in the middle of moving (again), I can't get 
that one out for now.


I do however have various pieces of source code from which I can whip 
up another test program. Will do so when I get back home later 
today/tonight.


If you could put the source(s) onto a github site or similar that I 
could then download and compile, that may be the best way for me to 
get permission to try it here at work. - Tim


Out of bad experience in the past, I am a bit reluctant to do that. I 
could possibly send you the necessary sources, but you would need 
Borland Pascal 7.0 to compile them...



The basic issue is that this is less of a problem of (Free)DOS, but 
what exactly the hardware/BIOS is providing and initializing in 
regards to the serial ports.


Yes, your first reply suggested that.  I have since started reading 
the UEFI spec ( 
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf 
).  I hope to understand how to access the serial port in UEFI legacy 
mode both with and without FreeDOS loaded as UEFI’s runtime functions 
are different than its bootload functions.  That may help explain why 
my serial communications efforts in FreeDOS presently fail. -Tim


I don't think that reading the UEFI specs are going to help you much, it 
all depends on what is effectively implemented. And if that is not in a 
(old-style) BIOS compatible way, ...


I just finished dinner at 11pm and need to get up at 5:30am again, I 
hope I get some time tomorrow night to get you something...


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-25 Thread Schoenfelder, Tim M

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 one out for now.

I do however have various pieces of source code from which I can whip up 
another test program. Will do so when I get back home later today/tonight.

If you could put the source(s) onto a github site or similar that I could then 
download and compile, that may be the best way for me to get permission to try 
it here at work. - Tim

The basic issue is that this is less of a problem of (Free)DOS, but what 
exactly the hardware/BIOS is providing and initializing in regards to the 
serial ports.

Yes, your first reply suggested that.  I have since started reading the UEFI 
spec ( http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf 
).  I hope to understand how to access the serial port in UEFI legacy mode both 
with and without FreeDOS loaded as UEFI’s runtime functions are different than 
its bootload functions.  That may help explain why my serial communications 
efforts in FreeDOS presently fail. -Tim

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-25 Thread Ralf Quint


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 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 
one out for now.


I do however have various pieces of source code from which I can whip up 
another test program. Will do so when I get back home later today/tonight.


The basic issue is that this is less of a problem of (Free)DOS, but what 
exactly the hardware/BIOS is providing and initializing in regards to 
the serial ports.


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-25 Thread Schoenfelder, Tim M

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

[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 system can not find the file specified.

It's not finding the object of the last redirection.(com1)

>echo hello

"hello" is not recognized as an internal or external command, operable program 
or batch file.

You seem to be directing the output of hello to echo, then to com1.

Unless the first ">" is part of your prompt I think you may have a syntax error.

Just tested W7-64 and got the same responses.

Bob

On Thu, Jun 21, 2018 at 7:52 PM, Ralf Quint 
mailto:freedos...@gmail.com>> wrote:
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 down some issues with (PCI) add-on RS-232 cards in computers that came 
without any serial port (USB only)...
You are very accomplished!

Well,... I am programming and in general "playing" with computers for 42 years 
this month. And almost 37 years of that with DOS, in various forms... ;-)

And all you need to configure any serial port,if it would be in any form, shape 
or color DOS (not only FreeDOS!) compatible in the first place would be the 
MODE command.
But it seems kind of odd to have an UEFI based PC that still has true RS-232 
serial ports... :?
The preferred PCs were ordered with these com ports.
Are they on-board or are those ports on any kind of add-on cards? In case of 
the later, they might use most certainly non-(DOS/IBM-PC)-standard ports... 
(none of 2E8h, 3E8h, 2F8h, 3F8h)
I added a PCI card to only one of the handful of PCs that I’ve tested.  The 
rest (as old of PCs as I could find) already had a RS232 port built into the 
motherboard.  About half of the PCs were HP and about half were Dell.  The two 
newest PCs use a motherboard header to drive what appears to be a small PC 
board based RS232 connector (These were put on by the manufacturer and one of 
the two ports tested to work with FreeDOS at the manufacturer’s site).
Ouch! That sounds as if you might not actually have a proper DOS compatible 
RS-232 port, with a (to DOS/DOS programs) known UART, but some USB-to-RS232 
converter, which "kind of" usually work in Windows. Ran into such things when 
active in an Arduino user group here in town
What kind of proof/log that those ports "work in FreeDOS" did they provide?

I’ve installed FreeDOS and tested DOS serial communications on a number of 
different modern PCs at my company to date in relation to this project.  
Additionally, the manufacturer tested serial communication on one of the ports 
of these preferred PCs under FreeDOS.  The person who did that testing left the 
company before I got back to their support personnel about it though.

The PCs were instead ordered with Windows 10 though.  I just checked two 
different makes/models of the UEFI PCs.  They both have standard interrupts 
assigned to serial ports.  The HP machine allows me to change the interrupts 
though.  I’ve also tried using  the mode command to configure the serial port.  
Attempting to send ‘hello’ still errors as described in my initial email though.
Well, that would be my next question, in regards to find out what ports they 
are using, as to what they are showing in the Windows 10 device manager as the 
port address. That would be more important than the interrupt.

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).
Again, what is important would be to find that port address in the device 
manager. COM1 in that case should show up under "Ports (COM & LPT)", the the 
properties for COM1. Unfortunately, I do not have any Windows 10 computer 
around that has any serial (or parallel) ports anymore here where I could post 
some sample info as to how this could look right now...

Ralf

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>

Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term

Re: [Freedos-user] Difficulty with serial communications

2018-06-22 Thread Bob Pryor

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 system can not find the file specified.

It's not finding the object of the last redirection.(com1)

>echo hello

"hello" is not recognized as an internal or external command, operable
program or batch file.

You seem to be directing the output of hello to echo, then to com1.

Unless the first ">" is part of your prompt I think you may have a syntax
error.

Just tested W7-64 and got the same responses.

Bob


On Thu, Jun 21, 2018 at 7:52 PM, Ralf Quint  wrote:

> 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 down some issues with (PCI) add-on RS-232 cards in computers
> that came without any serial port (USB only)...
> You are very accomplished!
>
>
> Well,... I am programming and in general "playing" with computers for 42
> years this month. And almost 37 years of that with DOS, in various forms...
> ;-)
>
> And all you need to configure any serial port,if it would be in any form,
> shape or color DOS (not only FreeDOS!) compatible in the first place would
> be the MODE command.
> But it seems kind of odd to have an UEFI based PC that still has true
> RS-232 serial ports... :?
> The preferred PCs were ordered with these com ports.
>
> Are they on-board or are those ports on any kind of add-on cards? In case
> of the later, they might use most certainly non-(DOS/IBM-PC)-standard
> ports... (none of 2E8h, 3E8h, 2F8h, 3F8h)
>
> I added a PCI card to only one of the handful of PCs that I’ve tested.
> The rest (as old of PCs as I could find) already had a RS232 port built
> into the motherboard.  About half of the PCs were HP and about half were
> Dell.  The two newest PCs use a motherboard header to drive what appears to
> be a small PC board based RS232 connector (These were put on by the
> manufacturer and one of the two ports tested to work with FreeDOS at the
> manufacturer’s site).
>
> Ouch! That sounds as if you might not actually have a proper DOS
> compatible RS-232 port, with a (to DOS/DOS programs) known UART, but some
> USB-to-RS232 converter, which "kind of" usually work in Windows. Ran into
> such things when active in an Arduino user group here in town
> What kind of proof/log that those ports "work in FreeDOS" did they
> provide?
>
>
>
> I’ve installed FreeDOS and tested DOS serial communications on a number of
> different modern PCs at my company to date in relation to this project.
> Additionally, the manufacturer tested serial communication on one of the
> ports of these preferred PCs under FreeDOS.  The person who did that
> testing left the company before I got back to their support personnel about
> it though.
>
>
>
> The PCs were instead ordered with Windows 10 though.  I just checked two
> different makes/models of the UEFI PCs.  They both have standard interrupts
> assigned to serial ports.  The HP machine allows me to change the
> interrupts though.  I’ve also tried using  the mode command to configure
> the serial port.  Attempting to send ‘hello’ still errors as described in
> my initial email though.
>
> Well, that would be my next question, in regards to find out what ports
> they are using, as to what they are showing in the Windows 10 device
> manager as the port address. That would be more important than the
> interrupt.
>
>
>
> 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).
>
> Again, what is important would be to find that port address in the device
> manager. COM1 in that case should show up under "Ports (COM & LPT)", the
> the properties for COM1. Unfortunately, I do not have any Windows 10
> computer around that has any serial (or parallel) ports anymore here where
> I could post some sample info as to how this could look right now...
>
> Ralf
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_8099980729244582233_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
>

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Ralf Quint


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 down some issues with (PCI) add-on RS-232 cards in 
computers that came without any serial port (USB only)...

You are very accomplished!


Well,... I am programming and in general "playing" with computers for 42 
years this month. And almost 37 years of that with DOS, in various 
forms... ;-)


And all you need to configure any serial port,if it would be in any 
form, shape or color DOS (not only FreeDOS!) compatible in the first 
place would be the MODE command.
But it seems kind of odd to have an UEFI based PC that still has true 
RS-232 serial ports... :?

The preferred PCs were ordered with these com ports.

Are they on-board or are those ports on any kind of add-on cards? In 
case of the later, they might use most certainly 
non-(DOS/IBM-PC)-standard ports... (none of 2E8h, 3E8h, 2F8h, 3F8h)


I added a PCI card to only one of the handful of PCs that I’ve 
tested.  The rest (as old of PCs as I could find) already had a RS232 
port built into the motherboard.  About half of the PCs were HP and 
about half were Dell.  The two newest PCs use a motherboard header to 
drive what appears to be a small PC board based RS232 connector (These 
were put on by the manufacturer and one of the two ports tested to 
work with FreeDOS at the manufacturer’s site).


Ouch! That sounds as if you might not actually have a proper DOS 
compatible RS-232 port, with a (to DOS/DOS programs) known UART, but 
some USB-to-RS232 converter, which "kind of" usually work in Windows. 
Ran into such things when active in an Arduino user group here in town

What kind of proof/log that those ports "work in FreeDOS" did they provide?


I’ve installed FreeDOS and tested DOS serial communications on a 
number of different modern PCs at my company to date in relation to 
this project.  Additionally, the manufacturer tested serial 
communication on one of the ports of these preferred PCs under 
FreeDOS.  The person who did that testing left the company before I 
got back to their support personnel about it though.


The PCs were instead ordered with Windows 10 though.  I just checked 
two different makes/models of the UEFI PCs.  They both have standard 
interrupts assigned to serial ports.  The HP machine allows me to 
change the interrupts though.  I’ve also tried using  the mode command 
to configure the serial port.  Attempting to send ‘hello’ still errors 
as described in my initial email though.


Well, that would be my next question, in regards to find out what 
ports they are using, as to what they are showing in the Windows 10 
device manager as the port address. That would be more important than 
the interrupt.


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).


Again, what is important would be to find that port address in the 
device manager. COM1 in that case should show up under "Ports (COM & 
LPT)", the the properties for COM1. Unfortunately, I do not have any 
Windows 10 computer around that has any serial (or parallel) ports 
anymore here where I could post some sample info as to how this could 
look right now...


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Schoenfelder, Tim M

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 place?
UEFI has a legacy boot mode which apparently uses regular bios ROMS according 
to literature.  It also shuts off the secure boot mode though.
Ok, that's fine. I was just curious, after having a cursory look over the 
discussion at the HP forum you linked to that there would be some kind of 
hypervisor booting first involved...

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 down some issues with (PCI) add-on RS-232 cards in computers that came 
without any serial port (USB only)...
You are very accomplished!

And all you need to configure any serial port,if it would be in any form, shape 
or color DOS (not only FreeDOS!) compatible in the first place would be the 
MODE command.
But it seems kind of odd to have an UEFI based PC that still has true RS-232 
serial ports... :?
The preferred PCs were ordered with these com ports.
Are they on-board or are those ports on any kind of add-on cards? In case of 
the later, they might use most certainly non-(DOS/IBM-PC)-standard ports... 
(none of 2E8h, 3E8h, 2F8h, 3F8h)

I added a PCI card to only one of the handful of PCs that I've tested.  The 
rest (as old of PCs as I could find) already had a RS232 port built into the 
motherboard.  About half of the PCs were HP and about half were Dell.  The two 
newest PCs use a motherboard header to drive what appears to be a small PC 
board based RS232 connector (These were put on by the manufacturer and one of 
the two ports tested to work with FreeDOS at the manufacturer's site).

I've installed FreeDOS and tested DOS serial communications on a number of 
different modern PCs at my company to date in relation to this project.  
Additionally, the manufacturer tested serial communication on one of the ports 
of these preferred PCs under FreeDOS.  The person who did that testing left the 
company before I got back to their support personnel about it though.

The PCs were instead ordered with Windows 10 though.  I just checked two 
different makes/models of the UEFI PCs.  They both have standard interrupts 
assigned to serial ports.  The HP machine allows me to change the interrupts 
though.  I've also tried using  the mode command to configure the serial port.  
Attempting to send 'hello' still errors as described in my initial email though.
Well, that would be my next question, in regards to find out what ports they 
are using, as to what they are showing in the Windows 10 device manager as the 
port address. That would be more important than the interrupt.

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).
Tim

Ralf

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>

Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Schoenfelder, Tim M

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.

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 configure the HP PC's UEFI's com1 & com2 interrupts to the standard DOS 
interrupt values which still didn't work.
How are you booting FreeDOS on a UEFI PC in the first place?
UEFI has a legacy boot mode which apparently uses regular bios ROMS according 
to literature.  It also shuts off the secure boot mode though.

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?

And all you need to configure any serial port,if it would be in any form, shape 
or color DOS (not only FreeDOS!) compatible in the first place would be the 
MODE command.
But it seems kind of odd to have an UEFI based PC that still has true RS-232 
serial ports... :?
The preferred PCs were ordered with these com ports.

I've installed FreeDOS and tested DOS serial communications on a number of 
different modern PCs at my company to date in relation to this project.  
Additionally, the manufacturer tested serial communication on one of the ports 
of these preferred PCs under FreeDOS.  The person who did that testing left the 
company before I got back to their support personnel about it though.

The PCs were instead ordered with Windows 10 though.  I just checked two 
different makes/models of the UEFI PCs.  They both have standard interrupts 
assigned to serial ports.  The HP machine allows me to change the interrupts 
though.  I've also tried using  the mode command to configure the serial port.  
Attempting to send 'hello' still errors as described in my initial email though.

Tim

Ralf

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>

Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Ralf Quint


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 configure the HP PC’s UEFI’s com1 & com2 interrupts to the 
standard DOS interrupt values which still didn’t work.



How are you booting FreeDOS on a UEFI PC in the first place?

I am currently away from my FreeDOS programming stuff, I could send you 
some diagnostic tool either tomorrow or over the weekend...


And all you need to configure any serial port,if it would be in any 
form, shape or color DOS (not only FreeDOS!) compatible in the first 
place would be the MODE command.
But it seems kind of odd to have an UEFI based PC that still has true 
RS-232 serial ports... :?


Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Schoenfelder, Tim M

-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:
> 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 curiosity, does it help if you identify the port as "com1:"?
Devices in DOS use trailing colons as identifiers.

It causes the same error.

> My protocol analyzer is setup for 9600, 8, n, 1 on the other end of the
> serial cable.  It should see any bits coming across the serial connection
> (this scenario worked for the cmd window in win10 but not with FreeDOS as
> primary OS or with VMWare in Win10).  However, this same command works fine
> in a cmd window under Windows 10 on the same computer…its just that windows
> won’t run my 16bit software program.

Which 16bit program is it?

HP495x.exe (it uses COM1 or COM2 for serial communications.  This is appears to 
be the crux of my issue as all new hardware uses a UEFI instead of a BIOS)

64bit Win10 does not run 16bit programs native, but there are work
arounds.  One thing I'd look at is vDos Plus.  vDos Plus is a port of
the open source DOSbox emulator written to allow old DOS games to be
run on non-DOS systems. vDOS is specifically intended to run character
mode business apps, and drops the support for PC graphics and sound.
I run several old DOS programs on a 64bit Win10 box with no problems,

See http://vdosplus.org/ for information and downloads.

It’s a good idea, however, I'll try to verify that it can handle serial 
communications first.

> Any ideas as to what to do to make FreeDOS serial communications work?

See above.

Thank you for your reply!

> Timothy Schoenfelder
__
Dennis

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Schoenfelder, Tim M

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 configure the HP PC's UEFI's com1 & com2 interrupts 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, 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 communications is working as described in this HP post 
without any success:  
https://h30434.www3.hp.com/t5/Desktop-Operating-Systems-and-Recovery/RS232-Serial-Communications-via-FreeDOS-is-not-working/td-p/6585759

If I try writing something to the port, it fails as follows:

>echo hello > com1
>error reading from device com1 write fault
>(A)bort (I)gnore (R)etry (F)ail
I can then hit the 'A' key twice to exit out of it.

My protocol analyzer is setup for 9600, 8, n, 1 on the other end of the serial 
cable.  It should see any bits coming across the serial connection (this 
scenario worked for the cmd window in win10 but not with FreeDOS as primary OS 
or with VMWare in Win10).  However, this same command works fine in a cmd 
window under Windows 10 on the same computer...its just that windows won't run 
my 16bit software program.

My goal is to get HP495x.exe to communicate serially to HP Protocol Analyzers 
on newer hardware that can be maintained.  HP495x.exe was designed to work with 
MS-DOS (I forget which version off-hand).  I believe that the software was 
developed to use the actual interrupts.

Any ideas as to what to do to make FreeDOS serial communications work?
There isn't really anything in FreeDOS "to make serial communications work". 
FreeDOS relies on the BIOS setting up any serial device properly and is 
communicating through the BIOS with any properly initialized serial port. And a 
lot of software is bypassing DOS/BIOS in the first place and is accessing the 
serial ports directly...
What have you done to verify that the serial port(s) are being properly 
initialized by the BIOS in the first place?

Ralf

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=icon>

Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=link>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread dmccunney

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 curiosity, does it help if you identify the port as "com1:"?
Devices in DOS use trailing colons as identifiers.

> My protocol analyzer is setup for 9600, 8, n, 1 on the other end of the
> serial cable.  It should see any bits coming across the serial connection
> (this scenario worked for the cmd window in win10 but not with FreeDOS as
> primary OS or with VMWare in Win10).  However, this same command works fine
> in a cmd window under Windows 10 on the same computer…its just that windows
> won’t run my 16bit software program.

Which 16bit program is it?

64bit Win10 does not run 16bit programs native, but there are work
arounds.  One thing I'd look at is vDos Plus.  vDos Plus is a port of
the open source DOSbox emulator written to allow old DOS games to be
run on non-DOS systems. vDOS is specifically intended to run character
mode business apps, and drops the support for PC graphics and sound.
I run several old DOS programs on a 64bit Win10 box with no problems,

See http://vdosplus.org/ for information and downloads.

> Any ideas as to what to do to make FreeDOS serial communications work?

See above.

> Timothy Schoenfelder
__
Dennis

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Difficulty with serial communications

2018-06-21 Thread Ralf Quint

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 communications is working as described in this 
HP post without any success: 
https://h30434.www3.hp.com/t5/Desktop-Operating-Systems-and-Recovery/RS232-Serial-Communications-via-FreeDOS-is-not-working/td-p/6585759

If I try writing something to the port, it fails as follows:

>echo hello > com1

>error reading from device com1 write fault

>(A)bort (I)gnore (R)etry (F)ail

I can then hit the ‘A’ key twice to exit out of it.

My protocol analyzer is setup for 9600, 8, n, 1 on the other end of 
the serial cable.  It should see any bits coming across the serial 
connection (this scenario worked for the cmd window in win10 but not 
with FreeDOS as primary OS or with VMWare in Win10).  However, this 
same command works fine in a cmd window under Windows 10 on the same 
computer…its just that windows won’t run my 16bit software program.

My goal is to get HP495x.exe to communicate serially to HP Protocol 
Analyzers on newer hardware that can be maintained.  HP495x.exe was 
designed to work with MS-DOS (I forget which version off-hand).  I 
believe that the software was developed to use the actual interrupts.

Any ideas as to what to do to make FreeDOS serial communications work?

There isn't really anything in FreeDOS "to make serial communications 
work". FreeDOS relies on the BIOS setting up any serial device properly 
and is communicating through the BIOS with any properly initialized 
serial port. And a lot of software is bypassing DOS/BIOS in the first 
place and is accessing the serial ports directly...
What have you done to verify that the serial port(s) are being properly 
initialized by the BIOS in the first place?

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

52 matches

Mail list logo