I think that I understand what Daniel is saying ... it's not a matter of contention but a matter of cpu updates and raster updates of the bit-map occurring at slightly different frequencies, and it only becomes obvious during animation-type activities. The traditional method to overcome these animation artifacts is to wait until the raster trace is outside the area that you're animating, and is possible only if you know approximately where the "gun" is at the moment. Old Apples suffered from this, because there was no way to know (screen refresh was transparent and there was no port to read that would tell the program what scan line was being drawn at any given moment). Other more sophisticated designs allowed you to wait until the proper instant using vblank interrupts and the like.

Mike

But there was. Have a look for Don Lancaster's "Vaporlock" (Enhancing your Apple II and IIe, Volume 2, enhancement 13, published in '85). Reads from the (write-only) casette output latch to sample a floating data bus, which holds the last data byte read by the video hardware, looks for video data stashed in areas of memory accessed only during refresh to sync the program flow to the refresh hardware, and from there on out "all" you have to do is use cycle-counted code to trigger your raster effects.

But, yeah, not trivial, and was extremely reliant on pecularities of the Apple II video systems, to the point where a single-cycle difference in the behavior of the II+ has to be compensated for, and it's unlikely to work as-is on clone hardware (and I have no idea if it works on the //c or IIgs). I doubt it was used in much commercial software.

Thanks for the correction, nyef! I had never heard of the floating bus method to detect raster position on the ][ and ][+, even though I have owned a ][+ for over 32 years! I'll have to dust it off and try some of the examples one of these days, because the likelihood of being able to try them successfully on AppleWin seems a bit slim. Of course, maybe I shouldn't assume, since I've already put my foot in my mouth at least once today!

Mike

Mike, you are absolutely right. That's exactly the situation I was trying to describe. I believe this is true for many constructions and in most cases it's no problem. Nice trick mentioned by nyef. That's pretty cool!

Regards,
Daniel

I decided to try to make my own V9958 video adapter. I've recently been learning Kicad and have done a few things so far, so I thought I would tackle this. I've designed a plug-in cartridge for the C64. Why? Just because it's a system I am familiar with and have spares if I blow things up I'm actually pretty new at this so anything is possible. I looked on the web and studied some of the MSX2 computer schematics, and other projects, like Dave Stevenson's MTX board etc.

Anyway, the board is nearing completion and I put a little webpage together for it (close by ):
http://www.6502.org/users/sjgray/projec ... index.html

As a bonus I also added a small Yamaha sound chip for fun! Comments/feedback are welcome, but please go easy with me if you find any major mistakes!

Steve

That looks very cool; you'll have to let everyone know how you get on. I'm especially keen to hear what kind of picture you get from the CXA1645. I tried various approaches to get a decent picture from the V9958, including a AD724 (PDF), but finally gave up and just went for a trani amp, the same one used in the MSX2. This was a shame because I really wanted a composite or SVideo output so I could attach my computer to a TV capture card - it seems finding a capture card that takes RGB video is almost impossible.

_________________
8 bit fun and games: https://www.aslak.net/

Take a look at Dave Stevenson's MTX+ board.
http://www.primrosebank.net/computers/m ... design.htm
He uses the CXA1645 too. Perhaps he can provide some insights or pics?

Have you tried running the RGB video into one of the new "SCART to HDMI" adapters, then feeding that into an HDMI recorder (those designed for recording people playing video games)?

Steve

I've got the "other" MTXplus prototype system, enclosed a high res photo of the display on a 1280 x 720 LCD TV.

The VDP/CXA1645 is outputting an NTSC signal to the TV via SCART

The fringing is a camera artefact, as there is banding on the display though maybe not quite as evident as it is with the 9929A in the original MTX.