The OSSC Pro is actually one of my go-to in my workspace setup. Big fan of it, highly recommend.
A problem here is that it doesn't have composite input like you'd need for the Apple II. So you'd need a Koryuu or the add-on I think they're selling now, which complicates things a bit. A solvable problem, of course, and maybe I should've included that in my post as well. Probably would have if it was a bit more serious!
This is the same debate as "Home Assistant vs Google Assistant" or "Linux on the Laptop vs Windows/Mac". If you love poking around and tweaking things OSSC is on an absolute sense capable of a few more things at the cost of significantly more pain. I'll stick with Retrotink.
idk about the pain. IMHO it's pure FUD. Generally speaking, it just works. Literal plug and play.
And I'm not saying this randomly. I have had my OSSC for years, and I use it with ample variety of hardware, including PC8801, PC9801, Amiga, MSX, IBM PC clones (8086, 486, Athlon) and the usual console suspects.
With adjustment, it works to perfection. For the Amiga (and only the Amiga) I did input pixel perfect timings. It's easy and, on that platform, it makes a difference. These timings seem good on both OCS/ECS and AGA.
I can hardly justify it, but I love my OSSC enough that I am planning on a OSSC Pro in the future. That way I will be able to divide my hardware across two rooms.
I still find it nearly impossible to get good video captures from my Apple II for demoscene purposes
the best I can get is an old composite->USB capture device which mostly does a good job but struggles with lo-res graphics (grey ends up being closely spaced black/white lines)
I have a retrotink 2 but to capture things I have to run it through an additional HDMI->USB capture device and that's not the best and I can't get the sound to sync up that way. (I'm doing all of this with OBS/Linux which probably isn't helping things)
not sure if getting an even more expensive retrotink 5 would help
"Grey is just closely spaced black/white lines" is an interesting problem to have; grey on the Apple II is always closely spaced lines, but the usual expectation is your TV will process it out (or just won't be high enough dot pitch to see the lines). So it seems like you might need a worse capture device?
These days I've been using a standalone AVerMedia ExRecorder 330 for HDMI captures, that's how the ones in the blog were captured (via the 5X, of course). The older blog posts I link to I think I was still mostly using an Elgato but it didn't work at all on Mac, so I can't imagine their Linux support is much better.
the problem is I have a whole box of composite capture cards and only one actually does a reasonably good job. I feel like it'd get expensive doing the same thing with HDMI capture boards.
My other big problem with HDMI capture is trying to capture mockingboard audio at the same time, I forget if in your reviews you cover that aspect of things
An interesting problem! How do the HDMI cards look? I have one but my Apple is not working at the moment at I haven't tried it yet. They are clever devices that snoop the bus and replicate the video do it might not be suitable for demo purposes. Then again, they are programmable hehe
I have to admit I'm being difficult here and want to capture the output of the composite port from the actual Apple II video circuitry. I feel like having a raspberry Pi replace the video circuitry is cheating somehow, and I know that's inconsistent of me because I'm often using a modern floppy disk replacement.
even if I had an HDMI card it wouldn't help with my other problem which is trying to capture HDMI video and mockingboard sound at the same time with them ideally synced up to the exact 60Hz frame
Not familiar with demoscene needs, but might A2DVI card be of help? It seems to support all standard video modes at least. Alternatively, there's also VidHD.
As I understand the Apple II has three useful voltage levels being sync, black, and white, with color being generated by alternating black and white?
The CXADC sounds interesting but unfortunately drops raw samples upon seeing input sync pulses unless you greatly decrease signal amplitude (which may be fine given it's 1-bit). I wonder if inverting the composite signal would bypass this. Alternatively the Domesday Duplicator is more expensive and may not be intended for composite signals. TBH I wonder if an ARM microcontroller could PLL to the sync pulses, sample the active signal digitally, and output a HDMI signal for a capture card (transmitting to a PC via the Pi Pico's 12 Mbit/s USB is marginal).
But did they actually mean literally to use ][ as square brackets. Or is it merely an approximation that is meant to be read as Roman numeral two. And then people in that time writing it as ][ because Unicode didn't even exist yet. And then people stuck with that.
I don't know what the confusion could be. That's the name of the product. It's '][' because that's a creative way to write 'II' which is a fun way of writing '2.'
Just like the Apple //c
I'd rather the open source hardware OSSC[0] or OSSC Pro[1].
0. https://videogameperfection.com/products/open-source-scan-co...
1. https://videogameperfection.com/products/ossc-pro/
The OSSC Pro is actually one of my go-to in my workspace setup. Big fan of it, highly recommend.
A problem here is that it doesn't have composite input like you'd need for the Apple II. So you'd need a Koryuu or the add-on I think they're selling now, which complicates things a bit. A solvable problem, of course, and maybe I should've included that in my post as well. Probably would have if it was a bit more serious!
This is the same debate as "Home Assistant vs Google Assistant" or "Linux on the Laptop vs Windows/Mac". If you love poking around and tweaking things OSSC is on an absolute sense capable of a few more things at the cost of significantly more pain. I'll stick with Retrotink.
idk about the pain. IMHO it's pure FUD. Generally speaking, it just works. Literal plug and play.
And I'm not saying this randomly. I have had my OSSC for years, and I use it with ample variety of hardware, including PC8801, PC9801, Amiga, MSX, IBM PC clones (8086, 486, Athlon) and the usual console suspects.
With adjustment, it works to perfection. For the Amiga (and only the Amiga) I did input pixel perfect timings. It's easy and, on that platform, it makes a difference. These timings seem good on both OCS/ECS and AGA.
I can hardly justify it, but I love my OSSC enough that I am planning on a OSSC Pro in the future. That way I will be able to divide my hardware across two rooms.
I still find it nearly impossible to get good video captures from my Apple II for demoscene purposes
the best I can get is an old composite->USB capture device which mostly does a good job but struggles with lo-res graphics (grey ends up being closely spaced black/white lines)
I have a retrotink 2 but to capture things I have to run it through an additional HDMI->USB capture device and that's not the best and I can't get the sound to sync up that way. (I'm doing all of this with OBS/Linux which probably isn't helping things)
not sure if getting an even more expensive retrotink 5 would help
"Grey is just closely spaced black/white lines" is an interesting problem to have; grey on the Apple II is always closely spaced lines, but the usual expectation is your TV will process it out (or just won't be high enough dot pitch to see the lines). So it seems like you might need a worse capture device?
These days I've been using a standalone AVerMedia ExRecorder 330 for HDMI captures, that's how the ones in the blog were captured (via the 5X, of course). The older blog posts I link to I think I was still mostly using an Elgato but it didn't work at all on Mac, so I can't imagine their Linux support is much better.
the problem is I have a whole box of composite capture cards and only one actually does a reasonably good job. I feel like it'd get expensive doing the same thing with HDMI capture boards.
My other big problem with HDMI capture is trying to capture mockingboard audio at the same time, I forget if in your reviews you cover that aspect of things
An interesting problem! How do the HDMI cards look? I have one but my Apple is not working at the moment at I haven't tried it yet. They are clever devices that snoop the bus and replicate the video do it might not be suitable for demo purposes. Then again, they are programmable hehe
I have to admit I'm being difficult here and want to capture the output of the composite port from the actual Apple II video circuitry. I feel like having a raspberry Pi replace the video circuitry is cheating somehow, and I know that's inconsistent of me because I'm often using a modern floppy disk replacement.
even if I had an HDMI card it wouldn't help with my other problem which is trying to capture HDMI video and mockingboard sound at the same time with them ideally synced up to the exact 60Hz frame
Not familiar with demoscene needs, but might A2DVI card be of help? It seems to support all standard video modes at least. Alternatively, there's also VidHD.
As I understand the Apple II has three useful voltage levels being sync, black, and white, with color being generated by alternating black and white?
The CXADC sounds interesting but unfortunately drops raw samples upon seeing input sync pulses unless you greatly decrease signal amplitude (which may be fine given it's 1-bit). I wonder if inverting the composite signal would bypass this. Alternatively the Domesday Duplicator is more expensive and may not be intended for composite signals. TBH I wonder if an ARM microcontroller could PLL to the sync pulses, sample the active signal digitally, and output a HDMI signal for a capture card (transmitting to a PC via the Pi Pico's 12 Mbit/s USB is marginal).
While researching LumaCode (similarly based on extracting digital signals from retro hardware) I came across RGBtoHDMI and https://lukazi.blogspot.com/2022/02/apple-ii-video-to-hdmi-u.... I have not read the article but it may be useful.
One thing, off topic kinda, that I always wonder when I see mention of said computer.
Why people don’t use the Unicode symbol for Roman numeral two?
Apple Ⅱ+
Because Apple itself wrote it with square brackets.
But did they actually mean literally to use ][ as square brackets. Or is it merely an approximation that is meant to be read as Roman numeral two. And then people in that time writing it as ][ because Unicode didn't even exist yet. And then people stuck with that.
I don't know what the confusion could be. That's the name of the product. It's '][' because that's a creative way to write 'II' which is a fun way of writing '2.' Just like the Apple //c
In my case I stick with ][ for the sake of nostalgia.
Yes, they did. It's written that way in early marketing material and documentation.
[dead]
I enjoy everything Nicole puts out. Her blog has gotten me through some very boring hours on the clock.