I believe there was an earlier posting about the Apple II video generation schematics being available. Where can I find this or

any other type of simple video generation schematics?

Thanks,

Bryan

The schematics for the entire Apple II computer are in the Apple II reference manual. Let me know if you don't have it, but I think it always came with the computer, and I'm sure you can find one at an electronics swap meet.

Garth Wilson

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I don't have an Apple II reference manual... I just thought that
the schematics were on the web someplace.

Thanks,

Bryan

Unless you're a real glutton for punishment, you won't want to use the Apple-][ model for your video. It's broken up into several segments, and is done the way it's done mainly to exploit the video refresh cycle in order to provide DRAM refresh for the 3 banks of DRAM's on the ][+ board. The way it's done is clever, however, in that, since the video refresh memory access is done during Phase-1, the CPU can do its work in Phase-2 and never hash the screen. If you have a main processor at 1 MHz, and assign its drawing tasks to 3 additonal processors, one in each color plane, you can do the same thing, only much more simply and elegantly. IF you want the graphic manipulations to go really fast, then you can use a bitmap that's quartered, i.e. use four CPU's, one for each quadrant, and if you use color, use three for each quadrant. Let the main CPU pass parameters to each of the other processors through shared but undisplayed memory and have them update the display during vertical blanking. That way, the main CPU can do his work without disrupting the display, the four or 12 other CPU's can do their work on their little 256x192 pixel fields, or whatever you decide, and, the refresh logic can have access to it during the time when it's not blanking, which is when the video processors do their updates. Since large fast SRAMS are reqdily available, refresh isn't an issue.

Quite a notion, eh? Consider, too, that you don't need a 6545 or the like, since you can program yet another CPU to generate the video timing for you. (see Don Lancanster's Cheap Video Cookbook)

Uli

>The way it's done is clever, however, in that, since the video
>refresh memory access is done during Phase-1, the CPU can do its
>work in Phase-2 and never hash the screen

Yeah, pretty clever, and accounts for the odd clock speed that's slightly off of 1MHz. I knew someone who highly modified his Apple II to make it run at around 3MHz, but I don't know any details.

> (see Don Lancanster's Cheap Video Cookbook)

Do you know the publisher or where it's available?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well, modifying the Apple-][ to run at something like 3 MHz is a difficult task, since the memory cycle length is dependent on the video refresh rate and has to happen twice per CPU clock cycle. The cycle time of DRAMs of the Apple-][ era is on the order of 450 ns, so shortening the cycle is a bit difficult without ripping out all the DRAM memory (you don't have to rip it out literally, but you do have to replace it with something capable of the higher speed and then provide a window during every CPU phase-1 during which the video logic, if it wants, can access the shared memory.) and replace it with a fast, probably static, ram that can be accessed by the video refresh logic during phase 1.

The Apple-][ also did a couple of odd and less-than-obvous things in order to maintain syncrhonization with normal NTSC timing, like skip a count every so often. I don't remember much about the associated details, not having been terribly interested in the Apple-][, but I certainly remember a colleague looking at the schematic and remarking that it did that.

I don't remember the publisher of this one of Don Lancaster's several books dealing with video circuitrly and the KIM. There were seveal, though. I think I bought this one, but haven't seen it in about 15 years. I may even have given it away. All it really says is that you can approximate NTSC video timing with port bits from whatever parrallel I/O peripherals you happen to use,if any. His reasoning was that at the time, video logic was lots of counters, gates, and a few shift registers, not to mention a RAM and a character generator ROM. Then there was the video combiner, which has to be there ...

All of that can be replaced by a properly coded 6502, with the exception of the video combiner, which is the circuitry that mixes the serialized video data, blanking, and sync signals together in to a single video output to go to your monitor.

Uli

>Do you know the publisher or where it's available?

Try looking at Don Lancaster's web site, "The Guru's Lair". It's at www.tinaja.com. If you haven't been to this one, it's a treat. He has all the books that he's written ava., copies of all the magazine articles he's written over the many years, & links to about everything you can image relating to electronic hobbies.

Give it alook.

Ted Melton

Running the entire Apple II at 3 Mhz is a bad idea.

It's much better to build a processor daughterboard which

has a fast 6502 with 48k of fast static RAM, and then map the following ranges from the Apple II into the fast processor's space with wait states:

$0400-$07ff (text page)
$2000-$5fff (hires pages 1 & 2)
$c000-fffff (I/O space & ROM)

On an Apple //e or //c, you have bank-switched main memory (extended 80 column card) so it's a little trickier, but on a Apple II or II+ this should suffice.

Toshi

Aside from my view that it would be TOTAL exercise in mental masturbation, I'd have to agree that it's a bad idea. The simple use of wait-states won't work, at least by itself, if you stick in a daughterboard with a faster set of RAM, etc. The problem is that the fast CPU has to be synchronized with the APPLE-][ or //c video circuitry. It would be straightforward enough to generate circuitry to detect and store data to be written to the display memory until a blanking interval occurs, except for the fact that the necessary signals aren't trivially avaiable from the daughterboard. You'd have to route the blanking signal(s) to the daughterboard somehow, perhaps hooking it to an interrupt or something if you didn't sync the fast CPU with the video, so I think that's what you'd have to do.

I gave up on trying to get even one bit of useful work from the Apple-//c by the way, and have chucked it, leaving only a couple of the ][+ types lying about. I do, of course, have lots of other 6502 applications in house, most of them faster than the Apples.

The Apples were designed as video toys and are, as a result, tightly coupled with the oddities of the video circuitry's timing. If they'd wanted to make a more general circuit, and, considering their market, there was no reason for them to do so, they could have slaved the video timing to the CPU rather than the other way around.

What is decent enough about the Apple-][+, in terms of "roll-yer-own" if you've stomach for that, is that it's built with little customed hardware. That means that you can fix it if it breaks and copy it if you are a glutton for punishment. Aside for cassette I/O software, I doubt there's much (other than one of the serial I/O boards, that relies on CPU timing, so you could, conceivably, build a version that runs the CPU at speed, subsequently synchronizing, via hardware, to the video timing whenever a read or write of the video memory is needed. This has to be done with sync logic because the video refresh is synchronous. That means that if you tread on the video space while it's trying to refresh the display, you'll get hash on the screen. Having a shadow of the video contents would be both trivial and practical with a fast shadow ram in use anyway, thereby allowing you to sync only on writes to the video memory. It could get somewhat trickier with overlapping your fast RAM on the I/O region. Some devices clear status bits if you physically read their data register (e.g. MC6850) and would always have a set bit anyway unless you physically read them.

Since my interest in the Apple computers has waned considerably, I'll leave most of this as an exercise for the studen (of Appledom).

Uli

Using wait states should work, I think.

On the Apple II (if I remember correctly) the DRAM refresh is
hidden by extending the clock out an extra 500 ns or something,
not by using wait states.

You need to sync with the Apple II clock anyway to do main memory access, so the DRAM refresh is still hidden from you.

Toshi

You don't need circuitry to "store data until a vertical blank occurs".

From the 6502's point of view, the video memory is accessible all the time. The system DRAM is twice as fast as necessary, and the 6502 and video circuitry interleave access to the DRAM.

The circuitry for an Apple II accelerator isn't that complex. If you can, you should dig up some of the older Apple II accelerators like the McT SpeeDemon or the Titan Accelerator //e. I seem to remember they had a handful of discrete logic, and some RAM, and not much else.

Toshi

No, I'm afraid you don't remember correctly. The DRAM refresh is accomplished by virtue of the fact the video refresh cycles through a sufficient range of addresses to access all the row addresses, consequently refreshing all the DRAMs. The video display refresh occurs during Phase-1, while the 6502 accesses the memory during Phase-2. This avoids collisions that might cause hash on the display.

Remember, too, the APPLE-][ uses 16K DRAMs which only have 7 row and column addresses. Refresh only requires the ROW be accessed. This refreshes all the columns in that row. The minimum cycle time for the 200ns DRAMs used in the Apple ][ was 375 ns, including a slightly longer than 200 ns access window and a similarly long "RAS-precharge" interval.

One thing to keep in mind is that the Apple-][ is a video display system with a computer built on top of it. If you want to build a computer with a video display system with today's technology, you'd probably not build it like the Apple-][. The principal objection I have to the Apple scheme is the fact that the video memory is broken up into several pieces rather than being contiguous. Today, with memory as fast as it is and with logic as cheap and dense as it is, you could trivially build a display system on a CPLD/FPGA and use a single SRAM for the CPU and another for the display subsystem. They are small and cheap. If you remove the DRAM and the address multiplexing logic from the Apple-][, more than half the board is gone. If you then remove the video timing logic, there's not much left at all.

What you might consider, particularly if performance is important to you, is putting a 6502 on a 64x128-byte display memory array. This represents 512 bits horizontally by 128 bits vertically. Now combine three such arrangements to give you 512x384 pixels. Add a fourth processor to generate the video timing under software control, as done in Lancaster's Cheap Video series, and let that same processor arbitrate between the three drawing processors. Now you have a really high-performance system for drawing, yet don't have to run the CPU fast. Now run the CPU's fast. The only thing you have to do is allow the display refresh process to have its, say, 10 ns access window once at a 1 MHz rate as it is done in the Apple, yet allow the drawing processors to run out of phase with that one CPU that drives the display. If you let your mind explore that for a while, you'll quickly see how you can do that.

Uli

Well, the Apple-][ was just a handful of discrete logic to handle the video display refresh and a handful of memory, which wasn't very dense back then, and the discrete logic to support it. Then there was a handful of discrete logic to support the CPU. Today you can do all that in one chip if you're ambitious. CYPRESS CPLD's or XILINX FPGA's will allow you to put on enough ROM, RAM, and the associated logic to do that in a single device.

Uli