I have a PowerBook 190cs that is running Debian SID. I would like to be
able to connect this PowerBook to an Ethernet network using an MPC-10 Ethernet PCMCIA card (I've confirmed that the card works in Mac OS 8.1).
It looks like there used to be some PCMCIA tools for 2.4 and 2.6
kernels, but it's not clear what to use for 4.x and 5.x kernels, or
whether PCMCIA support exists for m68k.
[1] http://www.g-mb.de/pcmcia_e.html
On 8/10/20 11:52 PM, Stan Johnson wrote:
I have a PowerBook 190cs that is running Debian SID. I would like to be able to connect this PowerBook to an Ethernet network using an MPC-10 Ethernet PCMCIA card (I've confirmed that the card works in Mac OS 8.1).
It looks like there used to be some PCMCIA tools for 2.4 and 2.6
kernels, but it's not clear what to use for 4.x and 5.x kernels, or
whether PCMCIA support exists for m68k.
PCMCIA works on m68k, I already used it on my Amiga 1200. Not sure about
68k Macs though.
One particular thing is that not all PCMCIA cards supported by the kernel will also work with the PCMCIA stack on Linux/Amiga [1]. So I had to be careful buying the right networking card.
You might have better luck with your Mac.
There was a discussion of the driver for PCMCIA support on the PB190
back in November 2009, but I don't believe anything was ever completed.
There's old code that worked for some cards back then, but it would need
to be updated to a current kernel, and even then probably needs some
work to get accepted.
...
ISTR the 190 and 5300 did have an optional infrared port. Unfortunately
the IRDA stack got removed from Linux in v4.17.
I've been working on other issues because the Powerbook 190 is limited to
40 MB of RAM (and that upgrade is probably unobtainable/unaffordable now).
Another limitation of the 190 is the missing FPU, which means the CPU has
to emulate those instructions which is slow. The FPU emulation in Linux is incomplete and the end result is that you can't run 'fio' for example.
The way I see it, implementing Localtalk support, better FPU emulation or
any of a dozen other issues would be more rewarding because that might
help with lots of Mac models (particularly those with more RAM).
On 8/10/20 8:03 PM, Finn Thain wrote:
...
ISTR the 190 and 5300 did have an optional infrared port. Unfortunately
the IRDA stack got removed from Linux in v4.17.
The PB 190 has infrared, which only supports Apple???s IRtalk in Mac OS.
But it doesn't matter for Linux since IRDA support has been removed.
On 8/10/20 8:03 PM, Finn Thain wrote:
The way I see it, implementing Localtalk support, better FPU emulation or any of a dozen other issues would be more rewarding because that might
help with lots of Mac models (particularly those with more RAM).
Supporting LocalTalk in Linux would be great for communicating with
older Macs (and even better if you're talking about TCP/IP over
LocalTalk, which would potentially allow Internet access via some LocalTalk/Ethernet bridges).
It sounds like there may not be enough PB 190 users to justify spending
any more effort in getting PCMCIA working in Linux.
On Mon, Aug 10, 2020 at 10:29:07PM -0600, Stan Johnson wrote:
On 8/10/20 8:03 PM, Finn Thain wrote:Do we have enough CPU time to implement LocalTalk fully in software
The way I see it, implementing Localtalk support, better FPU emulation or >>> any of a dozen other issues would be more rewarding because that mightSupporting LocalTalk in Linux would be great for communicating with
help with lots of Mac models (particularly those with more RAM).
older Macs (and even better if you're talking about TCP/IP over
LocalTalk, which would potentially allow Internet access via some
LocalTalk/Ethernet bridges).
without causing other issues? I believe it's a synchronous protocol,
and unless you're talking about one of the models with IOPs (IIfx,
Q900, Q950) or real DMA (Q660, Q840) the CPU will need to be
involved on a very fixed schedule. Is it possible to do that level
of real-time scheduling with a standard Linux kernel? If I'm
interpreting the docs correctly, we will have to talk to the serial controller around 8000 times per second (230kbit/s and 4 bytes at a
time from the ESCC) with very tight tolerances. Will it cause
problems to have the serial controller sending interrupts that
often? I suspect Apple just hogged the CPU during data transfer.
If we did have real LocalTalk support, we could use the ipddp module
to use a Linux box as the bridge. It has both modes according to the
code. I've never tried it myself, but it should work.
Brad Boyer
flar@allandria.com
Depends on the interrupt priority levels - if the SCC can preempt other interrupt handlers, and you do nothing but acknowledge the interrupt and
copy bytes to a buffer, this might be worth a try.
Protocol handling and moving buffer data to network buffers would be
left to a task queue, to run when a packet has been fully received.
Today's kernels are a lot smarter with locks than 20 years ago when this would have been impossible.
How large are the data packets involved? Is there a pseudo-DMA address
window for the SCC data port to used optimized access (moveml)? Does SCC access force a bus delay, or can the SCC be accessed at full rate?
Do we have enough CPU time to implement LocalTalk fully in software
without causing other issues?
I believe it's a synchronous protocol, and unless you're talking about
one of the models with IOPs (IIfx, Q900, Q950) or real DMA (Q660, Q840)
the CPU will need to be involved on a very fixed schedule.
Is it possible to do that level of real-time scheduling with a standard
Linux kernel?
If I'm interpreting the docs correctly, we will have to talk to the
serial controller around 8000 times per second (230kbit/s and 4 bytes at
a time from the ESCC)
with very tight tolerances.
Will it cause problems to have the serial controller sending interrupts
that often?
I suspect Apple just hogged the CPU during data transfer.
On Wed, 12 Aug 2020, Michael Schmitz wrote:
Depends on the interrupt priority levels - if the SCC can preempt otherIs there overhead in monitoring packets for node addresses? If so, any
interrupt handlers, and you do nothing but acknowledge the interrupt and
copy bytes to a buffer, this might be worth a try.
node on the network would consume CPU of every other node whenever it transmits... if true, it begs for IOP offload (or DMA).
Protocol handling and moving buffer data to network buffers would beGood questions. But I'm not going to dive into leaked source code or disassembled drivers to find answers. I might dig out the relevant books
left to a task queue, to run when a packet has been fully received.
Today's kernels are a lot smarter with locks than 20 years ago when this
would have been impossible.
How large are the data packets involved? Is there a pseudo-DMA address
window for the SCC data port to used optimized access (moveml)? Does SCC
access force a bus delay, or can the SCC be accessed at full rate?
and tech notes though.
On Tue, 11 Aug 2020, Brad Boyer wrote:
If I'm interpreting the docs correctly, we will have to talk to the
serial controller around 8000 times per second (230kbit/s and 4 bytes at
a time from the ESCC)
I think 8000 is an over-estimate. 230kbit/s is a baud rate not a bit rate, right?
On 12/08/20 12:45 PM, Finn Thain wrote:
On Wed, 12 Aug 2020, Michael Schmitz wrote:
Depends on the interrupt priority levels - if the SCC can preempt other >>interrupt handlers, and you do nothing but acknowledge the interrupt and >>copy bytes to a buffer, this might be worth a try.Is there overhead in monitoring packets for node addresses? If so, any
node on the network would consume CPU of every other node whenever it >transmits... if true, it begs for IOP offload (or DMA).
As far as I recall, the SCC can be programmed to only respond to a specific node address in synchronous mode. Packets destined to other nodes are just passed through.
But it's over 20 years since I last looked at the SCC databook, so I may be mistaken. My comments were based on that above assumption.
Protocol handling and moving buffer data to network buffers would beGood questions. But I'm not going to dive into leaked source code or >disassembled drivers to find answers. I might dig out the relevant books >and tech notes though.
left to a task queue, to run when a packet has been fully received.
Today's kernels are a lot smarter with locks than 20 years ago when this >>would have been impossible.
How large are the data packets involved? Is there a pseudo-DMA address >>window for the SCC data port to used optimized access (moveml)? Does SCC >>access force a bus delay, or can the SCC be accessed at full rate?
I didn't expect you to trawl through disassembly or leaked code - I just thought someone might remember.
The bit about bus delay should be possible to figure out from timing access to the SCC data port and compare to RAM access. That might already decide
the issue.
(and no, not suggesting you do that, either ... Just in case someone feels like a little kernel hacking for fun, if not profit)
On Wed, Aug 12, 2020 at 10:33:53AM +1000, Finn Thain wrote:
On Tue, 11 Aug 2020, Brad Boyer wrote:
If I'm interpreting the docs correctly, we will have to talk to the
serial controller around 8000 times per second (230kbit/s and 4 bytes at >>> a time from the ESCC)
I think 8000 is an over-estimate. 230kbit/s is a baud rate not a bit rate, >> right?
Maybe? What information I do have is a little limited, and not very
detailed on that sort of thing.
Brad Boyer
flar@allandria.com
Finn is right - that's a baud rate, not bit rate. I'm a little hazy on whether SDLC uses start and stop bits at all - I'm guessing it does not, making baud rate almost equal to bit rate (not considering node address and prefix). Still close to 7.2 kHz interrupt rate.
The bit about bus delay should be possible to figure out from timing
access to the SCC data port and compare to RAM access. That might
already decide the issue.
I suspect Apple just hogged the CPU during data transfer.
This 26 ms interval will cause missed timer interrupts and system clock drift, unless the timer interrupt was polled too. (We could probably poll
all of the VIA 1 interrupt sources for the duration of the packet, but not with Egret hardware because of delays in that interrupt handler.)
Another consideration is raised in tech note TB 570. It says, "system services like AppleTalk require that interrupts not be disabled for much
more than 1/1000th of a second usually. This means if you are doing
something large during your interrupt routine (when all interrupts may be turned off), you could delay the AppleTalk interrupt so long that data
gets lost."
I think this is quite feasible for the majority of systems. A minority
might drop some packets depending on hardware configuration, etc.
On Wed, 12 Aug 2020, Michael Schmitz wrote:
The bit about bus delay should be possible to figure out from timing
access to the SCC data port and compare to RAM access. That might
already decide the issue.
The Guide to Macintosh Family Hardware says that SCC accesses are paced by the GLUE logic.
"The SCC requires 2.2 uS between accesses for its intemal lines to
stabilize; in the case of back-to-back accesses to the SCC, the GLUE
holds off the second access for that amount of time."
That's 454545 accesses per second (peak).
On Thu, Aug 13, 2020 at 11:51:57AM +1000, Finn Thain wrote:
This 26 ms interval will cause missed timer interrupts and system
clock drift, unless the timer interrupt was polled too. (We could
probably poll all of the VIA 1 interrupt sources for the duration of
the packet, but not with Egret hardware because of delays in that
interrupt handler.)
That will make for a really messy driver, but it could be done with some careful thought. It could also be made conditional on m68k so that a ppc based system wouldn't need it, since it can figure out how much real
time passed between timer interrupts with the timebase.
Another consideration is raised in tech note TB 570. It says, "system services like AppleTalk require that interrupts not be disabled for
much more than 1/1000th of a second usually. This means if you are
doing something large during your interrupt routine (when all
interrupts may be turned off), you could delay the AppleTalk interrupt
so long that data gets lost."
I think this is quite feasible for the majority of systems. A minority might drop some packets depending on hardware configuration, etc.
It sounds like the first step might be to audit all the other common
drivers to see which ones are disabling interrupts too long. I know we
do quite a bit of that.
Am 13.08.2020 um 12:58 schrieb Finn Thain:
On Wed, 12 Aug 2020, Michael Schmitz wrote:
The bit about bus delay should be possible to figure out from timing access to the SCC data port and compare to RAM access. That might
already decide the issue.
The Guide to Macintosh Family Hardware says that SCC accesses are
paced by the GLUE logic.
"The SCC requires 2.2 uS between accesses for its intemal lines to
stabilize; in the case of back-to-back accesses to the SCC, the
GLUE holds off the second access for that amount of time."
Right, it now comes back to me at last - this is what we had used on the Atari and VME SCC serial drivers (no need for that with glue logic
though):
#define scc_reg_delay() \
do { \
if (MACH_IS_MVME16x || MACH_IS_BVME6000 || MACH_IS_MVME147) \
__asm__ __volatile__ ( " nop; nop"); \
else if (MACH_IS_ATARI) \
__asm__ __volatile__ ( "tstb %0" : : "g" (*_scc_del) : "cc" );\
} while (0)
The tstb takes around 600 ns. Is the Mac SCC clocked slower than the
Atari one (8 MHz)?
That's 454545 accesses per second (peak).
Many SCC operations need two accesses ... can the data register be read directly on the Mac SCC, or does it need a control register write first?
Polling for the entire packet might really be the only way.
On Wed, 12 Aug 2020, Brad Boyer wrote:
That will make for a really messy driver, but it could be done with some careful thought. It could also be made conditional on m68k so that a ppc based system wouldn't need it, since it can figure out how much real
time passed between timer interrupts with the timebase.
I would imagine that this 26 ms would be spent in interrupt context in the pmac_zilog driver. This may or may not impact the timekeeping on
powermacs. I don't know how interrupt priorities work on those platforms.
It sounds like the first step might be to audit all the other common drivers to see which ones are disabling interrupts too long. I know we
do quite a bit of that.
SCSI transfers happen either at IPL 2 or IPL 7. These days we use PDMA everywhere except for PSC machines (which should be using DMA but Linux drivers don't support it) and certain rare SCSI targets which can't keep
up. Limiting scatter/gather segments to 1024 B should meet the timing constraint.
It's possible that the floppy driver disables interrupts for too long. But apart from that, 1 ms seems quite feasible (at least until multiple controllers become busy).
BTW, feasibility is one thing but actually implementing Localtalk support
is another. DMA support for PSC machines and framebuffer acceleration are probably more important features than Localtalk. And I see debugging as
more important than adding features. So more volunteers are needed (as always).
BTW, feasibility is one thing but actually implementing Localtalk
support is another. DMA support for PSC machines and framebuffer acceleration are probably more important features than Localtalk. And
I see debugging as more important than adding features. So more
volunteers are needed (as always).
That's probably true. We have so much on the list already. I know there
were several other things I wanted to check out first. I have a wide
variety of video cards with various accelerator capabilities, plus a
couple NuBus DMA cards that should allow doing accelerated video even on
the early video cards without any extra logic beyond the basics.
I had hoped to work on the ADB drivers as well. It would be great to get
full ADB support working on the iMate which could potentially be used to
have real ADB support on anything with a USB port. The company that made
it has given hardware information for some of their other peripherals,
but I haven't tried asking for iMate documentation.
I was also hoping to get some enhancements for the IOP core to fully re-initialize the IOP kernel which should allow us to manage the bypass
mode directly.
However, that also means finding the resources in the ROM that contain
the kernel and device drivers for the IOP.
On Fri, 14 Aug 2020, Brad Boyer wrote:
That's probably true. We have so much on the list already. I know there were several other things I wanted to check out first. I have a wide variety of video cards with various accelerator capabilities, plus a
couple NuBus DMA cards that should allow doing accelerated video even on the early video cards without any extra logic beyond the basics.
I suspect that the on-board video hardware is under-performing in Linux, especially on some Quadras. And Linux/mac68k also lacks multiple display support.
Reverse engineering NuBus cards is another story. ISTR that NetBSD made
some progress there. But it's not high on my list of priorities because there's any number of different cards and no way of knowing which ones are still around.
I had hoped to work on the ADB drivers as well. It would be great to get full ADB support working on the iMate which could potentially be used to have real ADB support on anything with a USB port. The company that made
it has given hardware information for some of their other peripherals,
but I haven't tried asking for iMate documentation.
That seems out-of-scope for the Linux/mac68k project (?)
I was also hoping to get some enhancements for the IOP core to fully re-initialize the IOP kernel which should allow us to manage the bypass mode directly.
I think SCC IOP bypass is enabled in PRAM, which means we can just leave
the ROM to manage that (or MacOS, if the user wants MacOS to boot before Linux). And if you succeed in reviving the swim_iop driver, there would be
no need to manage the SWIM/ADB IOP bypass either, right?
However, that also means finding the resources in the ROM that contain
the kernel and device drivers for the IOP.
That could be useful if MacOS carries firmware updates to fix bugs in the
IOP kernels and drivers stored in the ROM. End users could extract those resources from MacOS for use with the Linux firmware loader. I wonder
whether such bugs exist (?)
Multiple display support shouldn't be too difficult, but I think we
should do that by having real video drivers rather than just using
macfb. It would be similar to the way offb works for PCI PowerMacs,
where there is both a generic driver and individual drivers for each of
the onboard chips as well as the various common PCI cards.
I suppose we can just tell people to manage the serial switch setting in MacOS, but that seems clumsy.
I think macfb could be replaced entirely by simplefb and some nubus
drivers, now that nubus has actual drivers under the Linux driver model
(as of Linux v4.16).
As of Linux v5.1 you can configure SCC IOP bypass using /dev/nvram on
68k Macs. (I wonder whether PRAM reset would enable or disable
bypass...)
On Sat, 15 Aug 2020, I wrote, incorrectly:
I think macfb could be replaced entirely by simplefb and some nubus drivers, now that nubus has actual drivers under the Linux driver model
(as of Linux v4.16).
I was forgetting about palette operations. So macfb is actually required
for on-board video hardware.
As of Linux v5.1 you can configure SCC IOP bypass using /dev/nvram on
68k Macs. (I wonder whether PRAM reset would enable or disable
bypass...)
/dev/nvram functionality works on IIfx but not Quadra 900/950 models
because there's no Caboose driver yet. RTC and soft power control functionality are also missing on Quadra 900/950 for the same reason.
On Thu, Aug 20, 2020 at 11:15:28AM +1000, Finn Thain wrote:
On Sat, 15 Aug 2020, I wrote, incorrectly:
I think macfb could be replaced entirely by simplefb and some nubus drivers, now that nubus has actual drivers under the Linux driver
model (as of Linux v4.16).
I was forgetting about palette operations. So macfb is actually
required for on-board video hardware.
That's fine, although at least Valkyrie already has a separate driver as
it is also used in some PowerPC models. Would separating them out like
they are there make the code simpler?
I know there is also a separate driver for Control, which is the video
chip on the various PowerMac 7x00 models.
As of Linux v5.1 you can configure SCC IOP bypass using /dev/nvram
on 68k Macs. (I wonder whether PRAM reset would enable or disable bypass...)
/dev/nvram functionality works on IIfx but not Quadra 900/950 models because there's no Caboose driver yet. RTC and soft power control functionality are also missing on Quadra 900/950 for the same reason.
That might be a tough one. I've never heard of anyone finding good documentation on Caboose. This may be one thing that has to be
completely reverse engineered by disassembling the ROM code. Even on the various IIfx craziness, we still managed to find some basic information
to give us a head start.
The official board diagram for the Q900 shows Caboose connected to VIA1 instead of directly to the CPU. The MESS hardware information claims it
is a 68HC05 just like Egret and Cuda.
Perhaps we should try the via-cuda driver with ADB disabled and see what happens?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 221:14:56 |
| Calls: | 6,623 |
| Calls today: | 5 |
| Files: | 12,171 |
| Messages: | 5,318,094 |