On 3/24/2013 12:30 PM, Sheldon Simms wrote:
On 2013-03-24 04:58:57 +0000, Charlie said: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?No you weren't misunderstanding. However, that only slightly changes the proposal. The software then captures the data bytes being written to memory and stores them in it's own buffer, and then every cycle, it reads the appropriate byte out of its own buffer and proceeds as I already described.
That should work. It's how the Carte Blanche does it. Your idea has the advantage that you can process the video data to make it look more like what you would see on an NTSC type monitor. I'm unfamiliar with the capabilities of the BeageBone so I can't say whether there are any disadvantages, but if you (or someone) decide to use it I would suggest you make sure the BeagleBone system can monitor the data from the Apple slot without interruption from the OS. The timing of when the data is valid on the bus is critical. Take a look at Alex Freed's write_clk module (wrclk.v) in the Carte Blanche code.
Syncing to the Apple then is how the "appropriate byte" is first determined. Afterwards, the software can keep in sync with the Apple by maintaining it's own video counters.
For me this has proven more difficult than it sounds, but that is probably my fault. Anyway, I certainly wish you luck.
Charlie