Trash80toHP_Mini
NIGHT STALKER
It'd look good on that 1280x800 panel though!
Are you talking conversion to analog VGA, DVI like that sexy 1920x1200 panel, HDMI or straight to LVDS LCD speak?
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Mac Portable Video: Where to tap the source?
- Thread starter Trash80toHP_Mini
- Start date
Are you talking conversion to analog VGA, DVI like that sexy 1920x1200 panel, HDMI or straight to LVDS LCD speak?
Bunsen
Admin-Witchfinder-General
So far I've only skimmed most of this thread, but it seems worth pointing out that bbraun managed to capture video from the SE PDS, pipe it over USB, and display it on another computer, with a $12 STMicro ARM Discovery board. If his 68k hacking site is still around or wayback-able (I think it went offline a while ago?) there is a forum thread there about it.
Here's the link to the PDS video capture setup.
Downside of this idea is it takes 44 connections to the PDS slot and requires tight real-time code to run on the microcontroller, able to respond instantly to an interrupt and read the state of the address and data lines essentially *whenever* RAM is written to. (Don't forget the Portable is twice as fast as the SE.) Finding a microcomputer with a video output framebuffer (which you'd want to drive the new LCD) that has enough GPIO *and* is documented enough to allow fast bare-metal access to the GPU might be an issue. These things almost always rely on binary code bundles for driving the more elaborate bits, which is why most are only really fully supported under Linux, which isn't going to be responsive enough to handle the real-time element. It looks like the Beaglebone Black might have enough GPIO, and it has a couple realtime integer-only I/O processors (the "PRU") so... maybe that could work even with Linux still driving the display portion?
If all you want is a dingus that would allow you to replace the Portable's original display with an LCD that's a straightforward integer scale larger (like 1280x800 or 1920x1200, which are 2x2 and 3x3 respectively) an FPGA would clearly be the way to go. It's essentially the same project as this, just with more pixels. (And, presumably, you'd want to drive the LCD panel directly instead of generating VGA signals.)
Downside of this idea is it takes 44 connections to the PDS slot and requires tight real-time code to run on the microcontroller, able to respond instantly to an interrupt and read the state of the address and data lines essentially *whenever* RAM is written to. (Don't forget the Portable is twice as fast as the SE.) Finding a microcomputer with a video output framebuffer (which you'd want to drive the new LCD) that has enough GPIO *and* is documented enough to allow fast bare-metal access to the GPU might be an issue. These things almost always rely on binary code bundles for driving the more elaborate bits, which is why most are only really fully supported under Linux, which isn't going to be responsive enough to handle the real-time element. It looks like the Beaglebone Black might have enough GPIO, and it has a couple realtime integer-only I/O processors (the "PRU") so... maybe that could work even with Linux still driving the display portion?
If all you want is a dingus that would allow you to replace the Portable's original display with an LCD that's a straightforward integer scale larger (like 1280x800 or 1920x1200, which are 2x2 and 3x3 respectively) an FPGA would clearly be the way to go. It's essentially the same project as this, just with more pixels. (And, presumably, you'd want to drive the LCD panel directly instead of generating VGA signals.)
Trash80toHP_Mini
NIGHT STALKER
Nice, thanks so much for the info/analysis. One day we'll definitely need to replace these LCDs . . . if the plastics of the lids and cases don't moulder into dust piles underneath burying them. Good to know this craziness might work out someday. Might wanna find a different place to wedge the doohicky to run the LCD though.
I have an improbable dream for filling that PDS with something of another nature. The PartsPortable I got a from someone (oP?) quite some years ago for hacking away on has been given a reprieve. Now the plan is to attempt to get it up and running as a poison taste tester for the NASA Portable King of my AppleDisplay. PerformerNeu™ insanity, my resistance is futile.
h34r:
I have an improbable dream for filling that PDS with something of another nature. The PartsPortable I got a from someone (oP?) quite some years ago for hacking away on has been given a reprieve. Now the plan is to attempt to get it up and running as a poison taste tester for the NASA Portable King of my AppleDisplay. PerformerNeu™ insanity, my resistance is futile.
h34r:
Last edited by a moderator:
Trash80toHP_Mini
NIGHT STALKER
Just occurred to me, the Processor is busy loading the frame buffer anytime the interrupt trips the FPGA's snooper circuits, so presumable it could be an SMT Kluge on the backside of a 32MHz 68030 Performer Portable accelerator?
A really fast FPGA? Though it would be dealing with the frame buffer loading at the 16MHz PDS clock, no?
Two functions, one PDS card? :blink:
A really fast FPGA? Though it would be dealing with the frame buffer loading at the 16MHz PDS clock, no?
Two functions, one PDS card? :blink:
techknight
Well-known member
The portable has its own video IC and RAM.
Trash80toHP_Mini
NIGHT STALKER
Huh? I don't see your point? From my read of the Portable Devnote, VDI and that 32K of of RAM appear no different to the CPU and OS than the simple frame buffer of the SE. VDI does housekeeping for the flat panel, merely offloading chores from the CPU.
VDI is addressed just as if it were RAM in a simple frame buffer setup, no? The two add up to nothing like the Video Subsystem of the SE/30.
Am I missing something here?
BTW, what's up with that wildly different Architectural Diagram in the Portable DevNote by comparison to the traditional Block Diagram in DCaDftMF?
VDI is addressed just as if it were RAM in a simple frame buffer setup, no? The two add up to nothing like the Video Subsystem of the SE/30.
Am I missing something here?
BTW, what's up with that wildly different Architectural Diagram in the Portable DevNote by comparison to the traditional Block Diagram in DCaDftMF?
If you were using an FPGA to do the screen conversion there won't be any "snooper" circuitry involved. A device that takes that route would simply hang off the connector for the original LCD screen and passively emulate it. It should be a pretty simple circuit, the only "strenuous" requirement is it'd either require an FPGA big enough to provide a 32k framebuffer (the most trivial way to do the necessary scan conversion) on-chip or you'd need an FPGA+a small SRAM. (Seriously, the level of complexity actually downgrades this possibly into CPLD territory.) The resulting LCD driver would probably be small enough to fit in the space freed up by removing the existing LCD, particularly assuming you implemented it as a custom PCB instead of using a FPGA dev board + more goo bodged together with a wiring loom.
So that said, I don't see any advantage of trying to wed this to an accelerator. No bus access is required.
Trash80toHP_Mini
NIGHT STALKER
THX, my friend. Usually you're reigning me back in these crazy endeavors, that's actually encouraging on the one front.
On the other, the original spec for the hack is to upgrade a "DOA LCD Portable" to backlit status with a side order of 2bit SE grayscale to one up the Backlit model considerably.
WAG would still be to put that FPGA on the "solder side" of the proposed 32MHz 68030/FPU Accelerator in the Luggable's PDS and run the new Display from there?
tk got me seriously thinking (always a mixed bag there :blink: ) about this project again after you'd posted the sorely missed bbraun's work on the SE. So I'd just finished putting the docs together as you posted!
On the other, the original spec for the hack is to upgrade a "DOA LCD Portable" to backlit status with a side order of 2bit SE grayscale to one up the Backlit model considerably.
WAG would still be to put that FPGA on the "solder side" of the proposed 32MHz 68030/FPU Accelerator in the Luggable's PDS and run the new Display from there?
tk got me seriously thinking (always a mixed bag there :blink: ) about this project again after you'd posted the sorely missed bbraun's work on the SE. So I'd just finished putting the docs together as you posted!
This has me scratching my head again: what are you talking about when you say this? The SE is strictly monochrome, 1 bit. Is there a particular add-on card you're referencing?
Trash80toHP_Mini
NIGHT STALKER
The aforementioned Architectural Diagram/Block Diagrams between the Macintosh Portable Developer Note vs. DCaDftMF:
5.4 Video Display Interface chip
The Video Display Interface chip is a custom IC designed to keep the
Macintosh Portable 68HC000 CPU from having to refresh the screen
(LCD display), thereby allowing the CPU to do more useful work. It
also generates all the signals necessary for the flat-panel display,
including the vertical and horizontal synchronization pulses. The
difference between the Macintosh Portable and the Macintosh SE
due to the function of this chip will have no effect on compatibility
of your software.
From the point of view of the 68HC000, the video interface is seen as
a continuous RAM array of 32,000 bytes (768 bytes reserved for later
use). The video controller interface is nominally 16 bits wide from
the 68HC000 to the Video Display Interface chip, but behaves like
main memory in that it is also byte addressable. The first pixel
displayed on the screen is the most significant bit of the first byte of
video RAM (at Screen_base), while the last pixel displayed on the
screen is the least significant bit of the last byte (at
Screen_base+32,000–1). Figure 5-3 shows the entry order of data in
terms of the pixels on the LCD. The pixels that are displayed between
the first and last are addressed in a similar fashion; the display can be
thought of as a linear array of bits.
Flat panel display description
The display gives a high quality presentation of alphanumeric and
graphic information on a 211 mm x 132 mm (8.31 in x 5.20 in) active
display area. Display intensity, contrast ratio, and pixel turn on and
turn off time are similar to CRT parameters (P4 phosphor).
Display Capacity 640 x 400 dots
Display Mode Reflective
Driving Method 8-bit Parallel
Interface CMOS Logic
Video signal timing
The Video Display Interfacechip generates the synchronization
signals (FLM, CL1, CL2) and data signals as shown in Figure 5-4. The
signal M is generated by the chip and is derived by dividing the FLM
frequency by two. CL1 is the horizontal synchronization signal; it
marks the end of a 640 pixel line. FLM is the vertical
synchronization signal; it marks the beginning of a new frame of
video every 16.32 milliseconds. This means that the display is being
refreshed at a 61.8 Hz rate.
The SE diagram from the Luggable Devnote is even more interesting as it includes the Address Map for quick reference.
5.4 Video Display Interface chip
The Video Display Interface chip is a custom IC designed to keep the
Macintosh Portable 68HC000 CPU from having to refresh the screen
(LCD display), thereby allowing the CPU to do more useful work. It
also generates all the signals necessary for the flat-panel display,
including the vertical and horizontal synchronization pulses. The
difference between the Macintosh Portable and the Macintosh SE
due to the function of this chip will have no effect on compatibility
of your software.
From the point of view of the 68HC000, the video interface is seen as
a continuous RAM array of 32,000 bytes (768 bytes reserved for later
use). The video controller interface is nominally 16 bits wide from
the 68HC000 to the Video Display Interface chip, but behaves like
main memory in that it is also byte addressable. The first pixel
displayed on the screen is the most significant bit of the first byte of
video RAM (at Screen_base), while the last pixel displayed on the
screen is the least significant bit of the last byte (at
Screen_base+32,000–1). Figure 5-3 shows the entry order of data in
terms of the pixels on the LCD. The pixels that are displayed between
the first and last are addressed in a similar fashion; the display can be
thought of as a linear array of bits.
Flat panel display description
The display gives a high quality presentation of alphanumeric and
graphic information on a 211 mm x 132 mm (8.31 in x 5.20 in) active
display area. Display intensity, contrast ratio, and pixel turn on and
turn off time are similar to CRT parameters (P4 phosphor).
Display Capacity 640 x 400 dots
Display Mode Reflective
Driving Method 8-bit Parallel
Interface CMOS Logic
Video signal timing
The Video Display Interfacechip generates the synchronization
signals (FLM, CL1, CL2) and data signals as shown in Figure 5-4. The
signal M is generated by the chip and is derived by dividing the FLM
frequency by two. CL1 is the horizontal synchronization signal; it
marks the end of a 640 pixel line. FLM is the vertical
synchronization signal; it marks the beginning of a new frame of
video every 16.32 milliseconds. This means that the display is being
refreshed at a 61.8 Hz rate.
The SE diagram from the Luggable Devnote is even more interesting as it includes the Address Map for quick reference.
Trash80toHP_Mini
NIGHT STALKER
As I understand it, the SE's actually a 2-bit grayscale architecture dumbed down to 1-bit just as the SE/30's 32-bit Color Architecture dumbed down to thae same least common denominator of Compact Mac's peculiar A/B Video setup.
IIRC ScuzzyGraph is the driver/hardware combo that breaks the SE free of its B&W shackles . . .
. . . more research . . .
h34r:
Trash80toHP_Mini
NIGHT STALKER
Dang, that was quick! This hack just got considerably more enticing for a lot more machines!
SCSIgraph II was a 1989 product (QuickDraw hack) compatible with Macs all the way back to the 512Ke. []
We could be talking 1280x1024/3-bit COLOR (possibly 4-bit?) output from a bone stock Luggable DOA LCD replacement option!
http://lowendmac.com/2013/scuzzygraph-and-scuzzygraph-ii/
http://32by32.com/category/hardware/
Do we have resident QuickDraw and SCSI boffins who can lend a hand here? I can never do any of this kind of work, I can only dream the dreams . . .
edit: This jibes with what I found to be surprising color output I remember seeing running (Oregon Trail?) under Mini Vmac on some tablet or other a few years back.
Has most of the work for re-creating this take on SCSIgraph II in hardware already been done in the Mac Emulation world? It would be insanely ridiculous if SCSI winds up being the best place to tap the source! :lol:
SCSIgraph II was a 1989 product (QuickDraw hack) compatible with Macs all the way back to the 512Ke. [
] We could be talking 1280x1024/3-bit COLOR (possibly 4-bit?) output from a bone stock Luggable DOA LCD replacement option!
http://lowendmac.com/2013/scuzzygraph-and-scuzzygraph-ii/
http://32by32.com/category/hardware/
Do we have resident QuickDraw and SCSI boffins who can lend a hand here? I can never do any of this kind of work, I can only dream the dreams . . .
edit: This jibes with what I found to be surprising color output I remember seeing running (Oregon Trail?) under Mini Vmac on some tablet or other a few years back.
Has most of the work for re-creating this take on SCSIgraph II in hardware already been done in the Mac Emulation world? It would be insanely ridiculous if SCSI winds up being the best place to tap the source! :lol:
Last edited by a moderator:
No. I don't know where you got that impression(* okay, I do, but see below), but hardware-wise it's *completely* a monochrome machine. Framebuffer works essentially the same way as the Mac Plus', IE, it steals 22k-ish of system RAM and displays it as a 1 bit linear bitmap...
The *only* part of the SE that supports "grayscale" (or color) is there is rudimentary *software* support in the original Quickdraw for doing spot color on the Color Imagewriter printer (IE, it supports the 8 colors the printer can do "natively".). Because the MacOS imaging model is unified for both video and printing the Scuzzygraph can leverage that support to give you a color display, but it has a lot of strings attached and it by no means counts as "2 bit grayscale". (It's black, white, 3 primary colors, and 3 complimentary colors, which on the printer would be achieved by overprinting but of course the video display can do directly.)
So, no, it has no "grayscale support" in *either* hardware nor software.
That said, sure, if you upgraded the Portable's internal display to a more modern LCD and then created some sort of Scuzzygraph clone (which wouldn't necessarily have to live on the SCSI port, if you were willing to make up your own driver it could go on the PDS) you could do 8 colors on it, but I suspect there might be issues with depending on that being the "primary" display; the Scuzzygraph was always the second display in the machine and some software didn't work with it, so unless you *also* provided some ability to display the output from the built-in 1-bit video on your replacement monitor/convince the machine that that part of the machine didn't exist and this new card *was* the primary display you'll have... issues.
Trash80toHP_Mini
NIGHT STALKER
Issues? We don' worry about no steenking issues! :lol:
BTW, another crazy montage just hit the visual cortex! :blink:
How about implementing a SCSI II PDS Card and SCSI2SD in the FPGA on the backside of that proposed 32MHz 68030/FPU Accelerator for the Luggable?
SCSI II on the 030 PDS been another of my impossible dreams since I first fired up the Rocket (SCSI II daughtercard ot put in danger at the time) in that prototyping step in the SuperIIsi™ SE/30 Stomper hack.
TANGENT!: In any event, I'm dying to see the most simple tile in that Portable mosaic 3D printed tomorrow. I just popped the modem cover plate off the back of the PartsPortable and can't wait to stick a MicroSD Card in there and not have it fall to the bottom of the case. They make little extension cables for those chiplets or SD adapters for them don't they?
BTW, another crazy montage just hit the visual cortex! :blink:
How about implementing a SCSI II PDS Card and SCSI2SD in the FPGA on the backside of that proposed 32MHz 68030/FPU Accelerator for the Luggable?
SCSI II on the 030 PDS been another of my impossible dreams since I first fired up the Rocket (SCSI II daughtercard ot put in danger at the time) in that prototyping step in the SuperIIsi™ SE/30 Stomper hack.
TANGENT!: In any event, I'm dying to see the most simple tile in that Portable mosaic 3D printed tomorrow. I just popped the modem cover plate off the back of the PartsPortable and can't wait to stick a MicroSD Card in there and not have it fall to the bottom of the case. They make little extension cables for those chiplets or SD adapters for them don't they?
MOS8_030
Well-known member
Trash80toHP_Mini
NIGHT STALKER
Very tempting, but for the time being I think I'll stick with the boxed SuperMac SuperView setup from 1992 that I have in my grubby little paws ATM. :
No mention of compatibility outside of Add Large Screen Color to your Black-&-White PowerBook! Doesn't list minimum hardware requirements or say it's NOT compatible with the Portable. The driver disk is (c)1990 and ISTR running it off my PowerBook 100. That's easily tested sometime soon. While I'm at it I'll try it with the SE when I get to that point as well.
Maybe I can bracket and then hull the Portable at the sweet spot.h34r:
No mention of compatibility outside of Add Large Screen Color to your Black-&-White PowerBook! Doesn't list minimum hardware requirements or say it's NOT compatible with the Portable. The driver disk is (c)1990 and ISTR running it off my PowerBook 100. That's easily tested sometime soon. While I'm at it I'll try it with the SE when I get to that point as well.
Maybe I can bracket and then hull the Portable at the sweet spot.
h34r:
Googling for the Superview it seems like most of the listings specify it's for the PowerBook 140, 145, or 170. All of those have Color Quickdraw, so if that's actually a requirement it won't go on the Portable. But if you *really did* run it on your PowerBook 100 then it apparently can adapt itself to work with the limited color support in classic Quickdraw and there's no good reason I can think of why it wouldn't. Only way to know is actually try it; presumably the driver software will tell you to get bent if your machine isn't supported.
Trash80toHP_Mini
NIGHT STALKER
There is that, hoping against hope that the Floppy 1990 copyright has something more to do with product and driver development than the label itself. PBs 100/140 weren't released until October, 1991.
Memories of MacPlaytime from the April, 2011 eBay ship date of the SuperView are pretty mixed up. I think one of the PowerBooks 100 nabbed in about that time frame was up and running, but I'm positively unsure of that. :blink:
PowerView is clearly based on the SCSIgraph model. I was kinda hoping Aura might have been acquired by SuperMac, but it appears they were hitched to Second Wave, whose product line survived into the PCI era. Dunno if Second Wave = 2nd Wave at this point though.
http://tidbits.com/article/3791
If I can find the new PowerBook 100, its AC adapter and the time to play with it all in one room after today's downsizing session I'll check it out.
Memories of MacPlaytime from the April, 2011 eBay ship date of the SuperView are pretty mixed up. I think one of the PowerBooks 100 nabbed in about that time frame was up and running, but I'm positively unsure of that. :blink:
PowerView is clearly based on the SCSIgraph model. I was kinda hoping Aura might have been acquired by SuperMac, but it appears they were hitched to Second Wave, whose product line survived into the PCI era. Dunno if Second Wave = 2nd Wave at this point though.
http://tidbits.com/article/3791
If I can find the new PowerBook 100, its AC adapter and the time to play with it all in one room after today's downsizing session I'll check it out.
Last edited by a moderator:
Trash80toHP_Mini
NIGHT STALKER
I got everything together in one spot and had some trouble with disk errors trying to copy that floppy over to the Monster. Switched to the original FDD I bought with my remaindered PowerBook 100 and everything that was Hinky is now Dory again. The installer disk's backed up.
You were right, installer comes right out an says it won't run on hardware sans Color QuickDraw. :-/
Not that I need this SuperView or a $600 ScuzzyGraph for that matter. As I said, I can't actually do any of this schiznit myself anyway. []
Where do things stand in the Mini Vmac etc. emulation communities? Is code out there already that may be remotely applicable to processing hijacked frame buffer data, moving it around inside the elusive FPGA critter and . . . whatever?
Anybody got a good copy of the ScuzzyGraph drivers? Picking those apart looks like it might be a productive approach? Something in them convinces a QuickDraw Mac to Ally Oop a 1280x1024 image onto the SCSI bus for its hardware to slam-dunk onto a display cable. 1280xwhatever in widescreen mode might be more interesting than doubling up the Portable's 640x400 output.
As far as the primary/secondary display thing goes, toggling back and forth in hardware seems like a plan?
Dunno if I'm sillier about this kinda stuff drinking coffee when I'm trying to wake up in the morning or trying to keep my eyes tracking together when I'm about to nod off at night? :
You were right, installer comes right out an says it won't run on hardware sans Color QuickDraw. :-/
Not that I need this SuperView or a $600 ScuzzyGraph for that matter. As I said, I can't actually do any of this schiznit myself anyway. [
] Where do things stand in the Mini Vmac etc. emulation communities? Is code out there already that may be remotely applicable to processing hijacked frame buffer data, moving it around inside the elusive FPGA critter and . . . whatever?
Anybody got a good copy of the ScuzzyGraph drivers? Picking those apart looks like it might be a productive approach? Something in them convinces a QuickDraw Mac to Ally Oop a 1280x1024 image onto the SCSI bus for its hardware to slam-dunk onto a display cable. 1280xwhatever in widescreen mode might be more interesting than doubling up the Portable's 640x400 output.
As far as the primary/secondary display thing goes, toggling back and forth in hardware seems like a plan?
Dunno if I'm sillier about this kinda stuff drinking coffee when I'm trying to wake up in the morning or trying to keep my eyes tracking together when I'm about to nod off at night? :
