Looks like my rotation concept proved:
blog.1bitrainbow.com
I looked at using one of the spare PIO state machines to rotate the frame buffer but I couldn’t find a way to make that work. In the end I took a step back and looked at a different approach. In its native portrait orientation, the LCD panel I had was 480px across. This was only 32px (1/16) less than the Macintosh screen width of 512px, which might be an acceptable compromise, so I tried getting the PIO that outputs the image data to drop every 16th pixel. This worked … sort of … but the result was unsatisfactory due to the common use if 1px wide vertical lines on the Mac interface such as window borders which would completely disappear at times. What I needed to do was make the emulator output a 480px wide image natively and this meant altering the Macintosh ROM file it uses.
I went about this all the wrong way but eventually managed it and compiled a version of pico-mac that outputs 480x342px … I was back in business. This compromise on resolution had a silver lining. Because I was now running the Mac screen across the full width of the LCD in portrait orientation, it meant the visible screen area was now smaller and that meant the Macintosh could be slightly smaller. It also solved the problem of having to factor in space for wide black margins on either side of the LCD which would have been necessary had I put a 512px wide image on a 640px wide LCD. It also meant the LCD flex cable was located at the bottom, not the side of the LCD so I would not have to bend it tightly.
Apart from an SPI interface to configure the LCD driver, the panel uses RGB565 (5 bits for the red and blue, and 6 for green) for the image data. That’s 16 data bits which was way more than I had available on the Pico. Fortunately, the original Macintosh had a black and white screen. It did not even support shades of grey. So I actually only needed to send one of two signals; all data bits high or all data bits low, and this could be done using the existing RGB data line provided for the pico-mac VGA out. I ran this past Matt but he said he didn’t think a single GPIO could drive that many inputs without using buffers so I began working on adding logic buffers to my PCB design.
In the end I didn’t need to because the backlight on the LCD panel is so bright, I found that only setting the most significant bit of each colour high still produced a bright enough image. Due to the asymmetry of RGB565, I found this gave a reddish tint but this disappeared if I drove the top two bits of each colour and gave be 50% more brightness. That is what I settled on and I have experienced no problems driving these 6 input lines from the same GPIO.
________________________________________________________________________
Seems like his initial approach to going from portrait to landscape mode for his LCD should work. He went with a different approach which worked out very nicely, reducing the size of his Pico-Mac-Nano. I'll have to take pics of my sketches illustrating the first iteration to post.
Capturing the full frame buffer and stripping the "Portrait Mode" pixels out of the buffer at right angles would yield a nicely rotated "Landscape Mode" input of the frame buffer to the LCD I'd think. Then Rotate LCD.
I'd like to build rotation hardware into the FPD card clones.
pico-mac-nano : a diminutive macintosh facsimile -
pico-mac-nano is a miniature, functional, scale replica of the original 1984 Apple Macintosh. It is 62mm high (no, that's not a typo) and has USB keyboard and mouse support. Below is a journal of the journey but if you just want to see it in action, start building one yourself, buy any of the parts
blog.1bitrainbow.com
The LCD
The final size was always going to be determined by the LCD panel which needed to be able to display the 512px x 342px screen buffer. I eventually settled on the smallest 640x480px LCD I could find at a sensible price which was a 2″ TFT panel . Unfortunately it transpired it was technically 480x640px i.e. portrait. I assumed using in landscape would be trivial but I was wrong. The driver being used on the panel (the ST7701S) offers no image rotation function so the only option would be to rotate the frame buffer on the Pico. The problem was that the Pico was already being seriously overclocked to make pico-mac responsive so there just weren’t a lot of processor cycles to spare.I looked at using one of the spare PIO state machines to rotate the frame buffer but I couldn’t find a way to make that work. In the end I took a step back and looked at a different approach. In its native portrait orientation, the LCD panel I had was 480px across. This was only 32px (1/16) less than the Macintosh screen width of 512px, which might be an acceptable compromise, so I tried getting the PIO that outputs the image data to drop every 16th pixel. This worked … sort of … but the result was unsatisfactory due to the common use if 1px wide vertical lines on the Mac interface such as window borders which would completely disappear at times. What I needed to do was make the emulator output a 480px wide image natively and this meant altering the Macintosh ROM file it uses.
I went about this all the wrong way but eventually managed it and compiled a version of pico-mac that outputs 480x342px … I was back in business. This compromise on resolution had a silver lining. Because I was now running the Mac screen across the full width of the LCD in portrait orientation, it meant the visible screen area was now smaller and that meant the Macintosh could be slightly smaller. It also solved the problem of having to factor in space for wide black margins on either side of the LCD which would have been necessary had I put a 512px wide image on a 640px wide LCD. It also meant the LCD flex cable was located at the bottom, not the side of the LCD so I would not have to bend it tightly.
Apart from an SPI interface to configure the LCD driver, the panel uses RGB565 (5 bits for the red and blue, and 6 for green) for the image data. That’s 16 data bits which was way more than I had available on the Pico. Fortunately, the original Macintosh had a black and white screen. It did not even support shades of grey. So I actually only needed to send one of two signals; all data bits high or all data bits low, and this could be done using the existing RGB data line provided for the pico-mac VGA out. I ran this past Matt but he said he didn’t think a single GPIO could drive that many inputs without using buffers so I began working on adding logic buffers to my PCB design.
In the end I didn’t need to because the backlight on the LCD panel is so bright, I found that only setting the most significant bit of each colour high still produced a bright enough image. Due to the asymmetry of RGB565, I found this gave a reddish tint but this disappeared if I drove the top two bits of each colour and gave be 50% more brightness. That is what I settled on and I have experienced no problems driving these 6 input lines from the same GPIO.
________________________________________________________________________
Seems like his initial approach to going from portrait to landscape mode for his LCD should work. He went with a different approach which worked out very nicely, reducing the size of his Pico-Mac-Nano. I'll have to take pics of my sketches illustrating the first iteration to post.
Capturing the full frame buffer and stripping the "Portrait Mode" pixels out of the buffer at right angles would yield a nicely rotated "Landscape Mode" input of the frame buffer to the LCD I'd think. Then Rotate LCD.
I'd like to build rotation hardware into the FPD card clones.
Last edited:
