On 3/23/2013 11:58 PM, Sheldon Simms wrote:
On 2013-03-24 02:43:41 +0000, Charlie said:On 3/23/2013 9:04 PM, Sheldon Simms wrote:On 2013-03-23 23:48:19 +0000, Charlie said:On 3/23/2013 7:01 PM, Sheldon Simms wrote:On 2013-03-23 20:53:33 +0000, Charlie said:The problem with any card that uses data from the slot bus is the inability to synchronize with the Apple video output. This is the way the Carte Blanche works and I'm pretty sure the Second-Sight card worked in a similar way (although I've never seen one). The Carte Blanche output visually is quite good although it doesn't have the NTSC look. This works well with most video but because of the lack of synchronization, programs that rely on timing with Vertical Blanking or interrupting to change palettes, modes, etc. don't do well. By the way sampling the bus doesn't have to be that fast. The Carte Blanche does it a 50MHz.50 Mhz is plenty fast enough, I was just wondering whether the Beaglebone can do it that fast.I agree, you probably only need to sample it faster than the Apple writes it which, of course, is much slower.Video sync is a solvable problem. Either take the signal where it is available (IIe slot 7, etc.)That would probably work with a //e but unfortunately not with a IIgs because the M2B0 signal is needed for the SHR graphics modes and M2B0 is not available on slot 7 (and the pin used for it in the other slots is used by CREF). I may try my hand at soldering a wire to connect the Sync signal to the Carte Blanche slot just to see how it works. I can't picture many people wanting to do this though.or write a program that will allow the VGA card/software to sync.Do you mean a program on the Apple II? I don't see how you could do that without interfering with other programs.Yes, an Apple II program you would run to allow the BeagleBone/VGA Card to sync. Once it's synced it can stay synced as long as it's powered. So you would run the sync program once and then you could do whatever you wanted while remaining synced until you powered down.Once the program synced the video you would still have to do something to keep it in sync, possibly count cycles of one of the clocks available on the slot bus. Whatever clock is used on the BeagleBone/VGA card to derive the VGA clock can't be counted on to be exactly the same as (or multiple of) the Apple.I wasn't worried about synchronizing the real VGA clock with the Apple, but instead just making sure that the software on the BB was drawing the same byte on the VGA screen as the Apple II is on it's composite output. I'm thinking of this as being basically an emulator video display driven by a real Apple II. Very roughly, my actual video emulation code works like this: doVideo (BYTE video_byte) { for i = 1 to 8 Pixel NTSCColor = NTSCFilter(video_byte & 1); DrawPixel(currentX, currentY, NTSCColor); updateCurrentXY(¤tX, ¤tY); video_byte >>= 1; end for } After each emulated instruction, this doVideo() function is called as many times as the number of cycles taken by the just-finished instruction. My thinking is that this could simply be running on the BB, and each time a video byte is sampled from the Apple bus, this function is called once. That's it. As long as the emulation code is drawing the same video byte in the same place on the screen as the Apple, it should work.
Maybe I'm misunderstanding you but it sounds like you are mistaking how the Apple bus signals work; The video data appears on the Apple bus when a program stores it in memory, not when it is being output. There is *no* correlation between when a video byte is written (appears on the bus) and when the corresponding pixel is drawn.
In other words you can't do it "on the fly" because each byte only appears once and not necessarily in any particular order.
Or am I misunderstanding what you are proposing? Charlie