Using parallel port on the Pegasos 2

Using parallel port on the Pegasos 2

[quan]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

I am playing around with the parallel port on the pegasos 2 and I noticed
the following issue:
The parallel port on startup is set to iobase 0x378, then later it gets
remapped to iobase 0x3bc.
When I tried writing to the 0x3bc location with
trace:memory_region_ops_write on, I get logs about writing to the location
'parallel', so far so good, but the writes don't make it through (it never
calls parallel_ioport_write* functions)

I traced it through where it calls portio_write, and inside the
portio_write code:
This line always fails for me:
 const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the list,
and the 'addr' in the code ranges from (0-15) (address relative to 0x3bc),
so it can never match the parallel io function to execute.

This seems like a bug to me. I think there is some issue where the
portio_list is not getting updated properly after the remapping to 0x3bc.

The other devices (Serial, RTC, PM, VGA) responds properly for me, so it is
only the parallel port that has this issue.

Quan

[-- Attachment #2: Type: text/html, Size: 1270 bytes --]

Re: Using parallel port on the Pegasos 2

[BALATON Zoltan]

On Sun, 28 Jul 2024, quan wrote:
> I am playing around with the parallel port on the pegasos 2 and I noticed
> the following issue:
> The parallel port on startup is set to iobase 0x378, then later it gets
> remapped to iobase 0x3bc.
> When I tried writing to the 0x3bc location with
> trace:memory_region_ops_write on, I get logs about writing to the location
> 'parallel', so far so good, but the writes don't make it through (it never
> calls parallel_ioport_write* functions)
>
> I traced it through where it calls portio_write, and inside the
> portio_write code:
> This line always fails for me:
> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the list,
> and the 'addr' in the code ranges from (0-15) (address relative to 0x3bc),
> so it can never match the parallel io function to execute.
>
> This seems like a bug to me. I think there is some issue where the
> portio_list is not getting updated properly after the remapping to 0x3bc.
>
> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it is
> only the parallel port that has this issue.

Is this something that broke recently or can the same be reproduced with 
QEMU v8.2.0. The relocation of these devices was implemented around commit 
35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.

Regards,
BALATON Zoltan

Re: Using parallel port on the Pegasos 2

[quan]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

I have tried this on qemu 8.2.0 (I downloaded it and compiled with
--enable-debug), this build does not seem to hit the breakpoint
portio_write function when writing to 0x3bc while it does on the latest
qemu git version.

Using the  trace:memory_region_ops_write option for 8.2.0, the other
devices like serial and rtc does get hit, but it never prints a write for
'parallel', as if its disabled somehow.

Quan

On Sun, Jul 28, 2024 at 2:17 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Sun, 28 Jul 2024, quan wrote:
> > I am playing around with the parallel port on the pegasos 2 and I noticed
> > the following issue:
> > The parallel port on startup is set to iobase 0x378, then later it gets
> > remapped to iobase 0x3bc.
> > When I tried writing to the 0x3bc location with
> > trace:memory_region_ops_write on, I get logs about writing to the
> location
> > 'parallel', so far so good, but the writes don't make it through (it
> never
> > calls parallel_ioport_write* functions)
> >
> > I traced it through where it calls portio_write, and inside the
> > portio_write code:
> > This line always fails for me:
> > const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
> > This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the
> list,
> > and the 'addr' in the code ranges from (0-15) (address relative to
> 0x3bc),
> > so it can never match the parallel io function to execute.
> >
> > This seems like a bug to me. I think there is some issue where the
> > portio_list is not getting updated properly after the remapping to 0x3bc.
> >
> > The other devices (Serial, RTC, PM, VGA) responds properly for me, so it
> is
> > only the parallel port that has this issue.
>
> Is this something that broke recently or can the same be reproduced with
> QEMU v8.2.0. The relocation of these devices was implemented around commit
> 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.
>
> Regards,
> BALATON Zoltan
>

[-- Attachment #2: Type: text/html, Size: 2473 bytes --]

Re: Using parallel port on the Pegasos 2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

On Sun, 28 Jul 2024, quan wrote:
> I have tried this on qemu 8.2.0 (I downloaded it and compiled with
> --enable-debug), this build does not seem to hit the breakpoint
> portio_write function when writing to 0x3bc while it does on the latest
> qemu git version.
>
> Using the  trace:memory_region_ops_write option for 8.2.0, the other
> devices like serial and rtc does get hit, but it never prints a write for
> 'parallel', as if its disabled somehow.

Before implementing relocation of these devices they were at default port 
numbers in QEMU v8.2.0 so parallel was at 0x378. Did you try with that 
address? You can use 'info mtree' command in QEMU monitor to check which 
regions are enabled and where they are.

Regards,
BALATON Zoltan

> Quan
>
> On Sun, Jul 28, 2024 at 2:17 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
>> On Sun, 28 Jul 2024, quan wrote:
>>> I am playing around with the parallel port on the pegasos 2 and I noticed
>>> the following issue:
>>> The parallel port on startup is set to iobase 0x378, then later it gets
>>> remapped to iobase 0x3bc.
>>> When I tried writing to the 0x3bc location with
>>> trace:memory_region_ops_write on, I get logs about writing to the
>> location
>>> 'parallel', so far so good, but the writes don't make it through (it
>> never
>>> calls parallel_ioport_write* functions)
>>>
>>> I traced it through where it calls portio_write, and inside the
>>> portio_write code:
>>> This line always fails for me:
>>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
>>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the
>> list,
>>> and the 'addr' in the code ranges from (0-15) (address relative to
>> 0x3bc),
>>> so it can never match the parallel io function to execute.
>>>
>>> This seems like a bug to me. I think there is some issue where the
>>> portio_list is not getting updated properly after the remapping to 0x3bc.
>>>
>>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it
>> is
>>> only the parallel port that has this issue.
>>
>> Is this something that broke recently or can the same be reproduced with
>> QEMU v8.2.0. The relocation of these devices was implemented around commit
>> 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.
>>
>> Regards,
>> BALATON Zoltan
>>
>

Re: Using parallel port on the Pegasos 2

[quan]

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

Ah I did not know about the relocation. Using 0x378 as the address works in
8.2.0. I do get the parallel_ioport_write messages now
parallel_ioport_write write [SW] addr 0x00 val 0x00

Quan


On Sun, Jul 28, 2024 at 5:33 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

> On Sun, 28 Jul 2024, quan wrote:
> > I have tried this on qemu 8.2.0 (I downloaded it and compiled with
> > --enable-debug), this build does not seem to hit the breakpoint
> > portio_write function when writing to 0x3bc while it does on the latest
> > qemu git version.
> >
> > Using the  trace:memory_region_ops_write option for 8.2.0, the other
> > devices like serial and rtc does get hit, but it never prints a write for
> > 'parallel', as if its disabled somehow.
>
> Before implementing relocation of these devices they were at default port
> numbers in QEMU v8.2.0 so parallel was at 0x378. Did you try with that
> address? You can use 'info mtree' command in QEMU monitor to check which
> regions are enabled and where they are.
>
> Regards,
> BALATON Zoltan
>
> > Quan
> >
> > On Sun, Jul 28, 2024 at 2:17 PM BALATON Zoltan <balaton@eik.bme.hu>
> wrote:
> >
> >> On Sun, 28 Jul 2024, quan wrote:
> >>> I am playing around with the parallel port on the pegasos 2 and I
> noticed
> >>> the following issue:
> >>> The parallel port on startup is set to iobase 0x378, then later it gets
> >>> remapped to iobase 0x3bc.
> >>> When I tried writing to the 0x3bc location with
> >>> trace:memory_region_ops_write on, I get logs about writing to the
> >> location
> >>> 'parallel', so far so good, but the writes don't make it through (it
> >> never
> >>> calls parallel_ioport_write* functions)
> >>>
> >>> I traced it through where it calls portio_write, and inside the
> >>> portio_write code:
> >>> This line always fails for me:
> >>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
> >>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the
> >> list,
> >>> and the 'addr' in the code ranges from (0-15) (address relative to
> >> 0x3bc),
> >>> so it can never match the parallel io function to execute.
> >>>
> >>> This seems like a bug to me. I think there is some issue where the
> >>> portio_list is not getting updated properly after the remapping to
> 0x3bc.
> >>>
> >>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so
> it
> >> is
> >>> only the parallel port that has this issue.
> >>
> >> Is this something that broke recently or can the same be reproduced with
> >> QEMU v8.2.0. The relocation of these devices was implemented around
> commit
> >> 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as
> well.
> >>
> >> Regards,
> >> BALATON Zoltan
> >>
> >

[-- Attachment #2: Type: text/html, Size: 3631 bytes --]

Re: Using parallel port on the Pegasos 2

[BALATON Zoltan]

On Sun, 28 Jul 2024, BALATON Zoltan wrote:
> On Sun, 28 Jul 2024, quan wrote:
>> I am playing around with the parallel port on the pegasos 2 and I noticed
>> the following issue:
>> The parallel port on startup is set to iobase 0x378, then later it gets
>> remapped to iobase 0x3bc.
>> When I tried writing to the 0x3bc location with
>> trace:memory_region_ops_write on, I get logs about writing to the location
>> 'parallel', so far so good, but the writes don't make it through (it never
>> calls parallel_ioport_write* functions)
>> 
>> I traced it through where it calls portio_write, and inside the
>> portio_write code:
>> This line always fails for me:
>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the list,
>> and the 'addr' in the code ranges from (0-15) (address relative to 0x3bc),
>> so it can never match the parallel io function to execute.
>> 
>> This seems like a bug to me. I think there is some issue where the
>> portio_list is not getting updated properly after the remapping to 0x3bc.
>> 
>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it is
>> only the parallel port that has this issue.
>
> Is this something that broke recently or can the same be reproduced with QEMU 
> v8.2.0. The relocation of these devices was implemented around commit 
> 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.

This commit also seems to break display with some VGA ROMs as can be 
reproduced with:

qemu-system-ppc -machine pegasos2 -bios pegasos2.rom -serial stdio -vga none -device ati-vga,romfile=ati-rage128progl16mb.VBI

where the romfile is something from 
http://vgamuseum.info/index.php/companies/item/111-ati-rage-128-pro for 
example). Until commit 35a6380b4ed27f^ you get picture on emulated VGA but 
not after (although I have no idea what a VGA BIOS has to do with the 
parallel port). Any idea how to fix this?

Regards,
BALATON Zoltan

Re: Using parallel port on the Pegasos 2

[Bernhard Beschow]

Am 25. Mai 2025 00:03:15 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>On Sun, 28 Jul 2024, BALATON Zoltan wrote:
>> On Sun, 28 Jul 2024, quan wrote:
>>> I am playing around with the parallel port on the pegasos 2 and I noticed
>>> the following issue:
>>> The parallel port on startup is set to iobase 0x378, then later it gets
>>> remapped to iobase 0x3bc.
>>> When I tried writing to the 0x3bc location with
>>> trace:memory_region_ops_write on, I get logs about writing to the location
>>> 'parallel', so far so good, but the writes don't make it through (it never
>>> calls parallel_ioport_write* functions)
>>> 
>>> I traced it through where it calls portio_write, and inside the
>>> portio_write code:
>>> This line always fails for me:
>>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
>>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the list,
>>> and the 'addr' in the code ranges from (0-15) (address relative to 0x3bc),
>>> so it can never match the parallel io function to execute.
>>> 
>>> This seems like a bug to me. I think there is some issue where the
>>> portio_list is not getting updated properly after the remapping to 0x3bc.
>>> 
>>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it is
>>> only the parallel port that has this issue.
>> 
>> Is this something that broke recently or can the same be reproduced with QEMU v8.2.0. The relocation of these devices was implemented around commit 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.
>
>This commit also seems to break display with some VGA ROMs as can be reproduced with:
>
>qemu-system-ppc -machine pegasos2 -bios pegasos2.rom -serial stdio -vga none -device ati-vga,romfile=ati-rage128progl16mb.VBI
>
>where the romfile is something from http://vgamuseum.info/index.php/companies/item/111-ati-rage-128-pro for example). Until commit 35a6380b4ed27f^ you get picture on emulated VGA but not after (although I have no idea what a VGA BIOS has to do with the parallel port). Any idea how to fix this?

Here an observation: Executing `info mtree` reveals that the parallel port gets mapped to 0x3bc - 0x3c3 which overlaps with some vga region (0x3c0 - 0x3cf). So the commit seems to expose a firmware bug in pegasos2.rom or in its default configuration. On real hardware both devices might respond such that the bug might not materialize there like in QEMU, but that's just a guess. Maybe one could work around that by decreasing the priority of the parallel io ports.

Best regards,
Bernhard

>
>Regards,
>BALATON Zoltan

Re: Using parallel port on the Pegasos 2

[BALATON Zoltan]

On Mon, 26 May 2025, Bernhard Beschow wrote:
> Am 25. Mai 2025 00:03:15 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>> On Sun, 28 Jul 2024, BALATON Zoltan wrote:
>>> On Sun, 28 Jul 2024, quan wrote:
>>>> I am playing around with the parallel port on the pegasos 2 and I noticed
>>>> the following issue:
>>>> The parallel port on startup is set to iobase 0x378, then later it gets
>>>> remapped to iobase 0x3bc.
>>>> When I tried writing to the 0x3bc location with
>>>> trace:memory_region_ops_write on, I get logs about writing to the location
>>>> 'parallel', so far so good, but the writes don't make it through (it never
>>>> calls parallel_ioport_write* functions)
>>>>
>>>> I traced it through where it calls portio_write, and inside the
>>>> portio_write code:
>>>> This line always fails for me:
>>>> const MemoryRegionPortio *mrp = find_portio(mrpio, addr, size, true);
>>>> This is due to the mrpio has the offset of 0x44 (0x3bc-0x378) in the list,
>>>> and the 'addr' in the code ranges from (0-15) (address relative to 0x3bc),
>>>> so it can never match the parallel io function to execute.
>>>>
>>>> This seems like a bug to me. I think there is some issue where the
>>>> portio_list is not getting updated properly after the remapping to 0x3bc.
>>>>
>>>> The other devices (Serial, RTC, PM, VGA) responds properly for me, so it is
>>>> only the parallel port that has this issue.
>>>
>>> Is this something that broke recently or can the same be reproduced with QEMU v8.2.0. The relocation of these devices was implemented around commit 35a6380b4ed27f (and the ones before that). Adding Bernhard to cc as well.
>>
>> This commit also seems to break display with some VGA ROMs as can be reproduced with:
>>
>> qemu-system-ppc -machine pegasos2 -bios pegasos2.rom -serial stdio -vga none -device ati-vga,romfile=ati-rage128progl16mb.VBI
>>
>> where the romfile is something from http://vgamuseum.info/index.php/companies/item/111-ati-rage-128-pro for example). Until commit 35a6380b4ed27f^ you get picture on emulated VGA but not after (although I have no idea what a VGA BIOS has to do with the parallel port). Any idea how to fix this?
>
> Here an observation: Executing `info mtree` reveals that the parallel 
> port gets mapped to 0x3bc - 0x3c3 which overlaps with some vga region 
> (0x3c0 - 0x3cf). So the commit seems to expose a firmware bug in 
> pegasos2.rom or in its default configuration. On real hardware both 
> devices might respond such that the bug might not materialize there like 
> in QEMU, but that's just a guess. Maybe one could work around that by 
> decreasing the priority of the parallel io ports.

Hmm, I haven't noticed that (only looked at the diff between working and 
non-working and saw it moved) but according to e.g. 
https://www.stanislavs.org/helppc/ports.html The original parallel 
interface had less ports so there was no overlap, maybe it's because we 
emulate EPP+ECP or other advanced features that the message from the Linux 
list mentions as not working at the default address on real machine 
either. So we may need to disable additional ports which probably do not 
exist on real machine unless enabled (which the firmware does not seem to 
do) or maybe changing priority as you say could help. Anybody wants to 
come up with a patch? I don't have time now and may forget later.

Regards,
BALATON Zoltan