I'm trying to implement the original video display in FPGA, but I can't find anywhere the actual parameters of the NTSC signal produced by the Apple-1.
My actual guess is that there are 262 lines (as per NTSC standard), and that the dot pixel frequency is obtained by dividing the main XTAL by two (14.31818 MHz / 2 = 7159090 Hz).
This would give a 455 pixel wide horizontal line (of which 280 is the active area: 40 columns x 7 pixels) that also matches with the 60.05 Hz refresh rate stated in the manual.
But I still don't know anything about the HSYNC and VSYNC signals, though I could use the standard values for NTSC to make it work (but it would be nicer to implement the original values).
To sum up:
dot frequency: 14.31818 MHz / 2
display: 455x262 dot pixels
active area: 280x192 pixels
line rate: 14318180/2/455 = 15734.26 Hz
frame rate: 14318180/2/(455*262) = 60.0544 Hz
Hsync: ?
Vsync: ?
Where can I confirm or reject the above numbers?
The horizontal line timing (or TV scan line) is 65 char rate clocks wide which are 7 dot rate clocks each.
The horizontal counter starts at $95 and counts up to $F9 before it reloads to $95.
Note that the lower 4 bits of the horizontal counter count in decimal (0...9, it's a 74160, not a 74161).
HSYNC time is from horizontal counter state $A0 to $A9 which is ~10us, which violates the NTSC standard, so many monitors and TV puke on the signal.
The VSYNC is not serrated so many monitors and TV lose horizontal synchronisation during the vertical sync period.
(See here: https://www.applefritter.com/content/how-fix-nonstandard-apple-1-video)
With an FPGA you can fix all these quirks with ease.
As far as I can tell your scan line count per frame and the frame rate is correct.
thank you! so if I got it correctly the horizontal counter goes like this:
95, 96, 97, 98, 99 front porchA0, A1, A2, A3, A4, A5, A6, A7, A8, A9 HSYNCB0, B1, B2, B3, B4, B5, B6, B7, B8, B9C0, C1, C2, C3, C4, C5, C6, C7, C8, C9D0, D1, D2, D3, D4, D5, D6, D7, D8, D9E0, E1, E2, E3, E4, E5, E6, E7, E8, E9F0, F1, F2, F3, F4, F5, F6, F7, F8, F9Do you also know when the characters start to be displayed ? is it at C0 (thus covering the C0-F9 range) or perhaps some point earlier?
And what about the vertical counter, at which line the characters get decoded ?
Regarding the serrated VSYNC, interestingly there is a similar issue in the FPGA (MiST platform) where there is an option to choose how HSYNC and VSYNC are blended together: by AND or by XOR.
nippur72, you are correct with the counting in your above post #3:
The character field starts at horizontal count $C0 and ends at horizontal count $F9.
At positions $C9, $D9, $E9, $F9, the real Apple-1 (originals and clones) have a crosstalk from the LASTH signal which makes a faint dot.
There are other faint dots by yet another crosstalk effect which swamp these in the character field, but in the first row of these dots the four culprits are solo and easily seen.
The counters in the Apple-1 count in a peculiar way. The vertical counter increments on the next CHAR RATE clock after the $F9 in the horizontal counter. So the portion of the scan line after the last visible character of a character line already has the next VCOUNT. Then comes the sync as described above, and then another 10 CHAR RATE clocks for the retrace and overscan. There is no real "front porch" or "back porch" in the Apple-1 video signal. It has no pedestal as required by the NTSC standard. It's just a nasty signal which pretends to be NTSC but it isn't. But for sure, Woz did all the timing with an absolute minimum number of TTL gates. The issue with the missing "porches" and "pedestal" is less severe for analog TVs but digital ones (i.e. LCD monitors / TVs) try to figure out the DC restore / clamp level during this time, and the black level, and depending on which solution was adopted by the designers of that IC it may fail miserably if the signal comes from the Apple-1. With a FPGA and only one resistor more in the video mixer you could do a real, fully standard conforming NTSC signal (except for the color burst, which is never needed for B&W).
The vertical position of the character field as such is determined by the VBL signal (vertical blank) which starts at VCOUNT $C0 and ends after VCOUNT $FF (rollover to $00) but the character field is delayed on the screen by 8 scan lines as the data which is displayed comes out of the 2519 shift register, which adds a 40 character delay. The blanking before the first visible character line happens in the 2519, too, as it was loaded with all zeros before. The blanking after the last visible character line happens the same way. You can see this when the 2519 is defective or pulled.
Note that the vertical counter also counts in a most peculiar way, after rolling over to $00 it counts up to $E0 in binary and then does this:
$E0
$E1
$E2 $E2 $E2
$E3
$E4 $E4 $E4
$E5
$E6 $E6 $E6
$E7
$E8 ... $FF
So there are 6 extra scan lines to make a total of 256 + 6 = 262 scan lines per frame.
Where the whole trick circuit really gets interesting is what happens when the character field scrolls. The vertical counter will jump back and another 40 MEM0 clocks will be added to the frame. This does a relative shift by 40 character positions in the 1k x 1 shift registers which looks like a scrolling process and even the cursor moves the same amount. To avoid garbage lines on the screen (residue of that process) the vertical blank activates the CLR signal which zeros all locations in the 1k x 1 shift registers above and below the stored character field. The visible character field, as explained above, is delayed by eight TV scan lines as it goes through the 2519.
If I were you I would not try to implement this shift register based character memory in an FPGA. Instead use RAM block and pointer counters to make it work as a ring buffer with a "cursor". Then you can toss away all the peculiar counting and make a much cleaner video timing in much fewer lines of code. But if you do this to learn how to code in Verilog or VHDL, the more lines of code you need to write the better ;-)
And for the serrated vsync, use the XOR. Woz had no 7486 TTL in the whole design so he could not do this. And adding one TTL package more just for the serrated vsync ... impossible. I did it with one transistor, three resistors, and one capacitor) as seen here:
https://www.applefritter.com/content/how-fix-nonstandard-apple-1-video
Even back in 1975 this would have been cheaper than to add another TTL. With FPGAs of today, generating a clean and fully standard conforming video signal costs next to nothing (except the development of the code). But even back in the 1970s, if you did a full custom IC, saving a few gates to avoid a good sync was pointless. Even the first TV tennis ICs and the Atari VCS had serrated vertical syncs. Otherwise they would have created *lots* of very angry customers.
UncleBernie, thank you for the detailed reply. I haven't seen all that explained with this level of accuracy anywhere -- it's very valuable information!
One more question regarding the vertical counter: you said that blanking goes from $C0 to $FF, does thins mean that the actual VSYNC signal is low (active) for all the 70 lines? Or the VSYNC time has smaller range of lines (e.g. 6 lines VSYNC low active and the rest 64 lines just empty screen)?
As you suggested I'm not going to reproduce the original diplay circuit in my FPGA implementation (at least for now) but I'll just have a functional clone, something that works like the real thing, but maybe with less quirks :-).
When starting from a "fresh" approach, with modern tools like Verilog and no constraints, it's all very easy indeed. In my MiST FPGA board I don't even have to deal with the actual video signal generation, I provide HSYNC, VSYNC and RGB outputs and the board automatically gives both composite and VGA-like video. Very straightforward.
I am amazed by the work Steve Wozniak has done trying to reduce the number of components, not only with the display but also with the ACI (which I also looking into).
In post #5, nippur72 wrote:
"I haven't seen all that explained with this level of accuracy anywhere -- it's very valuable information!"
Uncle Bernie comments:
Most of the information you can find on how the Apple-1 works is faulty. Lazy as I am, I relied on that bogus information myself until I found out it's bogus. Sigh. As I'm selling Apple-1 kits and coach "my" builders I had to understand how the circuit really works, despite it took me a lot of time to fathom it. Knowing how it really works is important to efficiently diagnose symptoms if it does not work correctly. For builders it's typically a bad solder joint or an IC pin which got bent when inserting the IC so it does not make contact (it's never the ICs because I only sell 100% tested and burned-in ones) but the worst case is when one of my burn-in machines dies and I need to find the culprit IC quickly. If I would need more than a few minutes to fix that then I would need to to raise my prices or give up selling these kits (as all the others did). So I know exactly what every IC and every gate in the Apple-1 does. Otherwise it would be impossible to do what I do (to fish out all these bad ICs so the builders have success, preferably on 1st power up).
To answer your question about the vblank and vsync in the Apple-1:
The VBL signal does not directly blank any of the video signal by itself. So throughout VBL being active you could produce video (a bad 74166 video shifter may do that ... pull it and bend away its pin #3, then re-insert, power up and wonder !).
What VBL does is to assert the CLR signal which in turn zeroes out all the 2504 ICs shift register bits coming up during the VBL period. This is essential to avoid trash to appear on the screen after a scrolling operation.
The vsync is a bit more tricky. It's generated by its own counter, the 74161 at PCB location D15, which also makes the vertical counter to "stutter" for the extra 6 scan lines as explained in my post #4. This is done by the /VINH signal (the schematic is wrong, the signal coming out of Q1 of D15 should have an inversion bar over it). On Q3 of D15 is the /VSYNC. Because of the "stutter" it is a bit confusing to relate it to the vertical counter. But if we agree the 262 scan lines count from 0 to 261, then the vsync is active from scan line 230 to 237 inclusive, for a total of 8 TV scan lines.
Hope this helps.
- Bernie
Great, thank you, my apple1-FPGA is now has a nice NTSC output on my Samsung CRT TV, I wanted to post a picture of it but I don't know to attach a .jpg here.
If I'm allowed, one more question: what is the blink rate of the cursor ? I guess there is a counter somewhere... :-)
ok found the blinking rate -- @p-lab told me there is a 555 configured to provide a 1.92 Hz signal
Yeah, roughly... ;-)
Just finished to measure my 555: 1.7Hz with a duty cycle of ~70%.
It's an RC so don't expect 100% accuracy against calculated value, also due to ageing of components.
If you stay around a period of 500ms it will be fine...
Cheers,
C.
what about the speed of the display device ? I need to slow down my naive FPGA implementation because it's too fast when compared to the real Apple-1.
What are the timimgs behind the ready bit of the display (PB7 of PIA) ?
In post #10, nippur72 asks:
"What about the speed of the display device ?"
Uncle Bernie answers:
The Apple-1 terminal section is able to output one character per TV frame (60 frames per second, so 60 characters per second max). Many people regard this as a drawback, but I see it as an advantage as I can read fast enough to follow the Apple-1 screen output without using some (non existing on the Apple-1) CTRL-Stop and CTRL-Continue key commands.
To correctly mimic the Apple-1 output rate, modify your FPGA code such that it takes one character per frame.
The ready bit is done by the automatic handshake in the PIA. When the 6502 writes to the port B, CB2 drops to "0" and the NAND gate C15-1 inverts the signal to "1" - which feeds back into PB7. This signal is the "DA" = Data Available signal to the terminal section. Once the character has been accepted, the terminal section makes a "0" pulse at /RDA which is exactly one CHAR RATE clock wide. This is too short for the PIA. So there is that B3-12 oneshot which is negative edge triggered and makes a 3.5 us wide pulse that the PIA input CB1 can see. The automatic handshake logic in the PIA then sets CB2 back to "1" and the PB7 will go "0". The software exits the BMI polling loop and may present the next character to the terminal section. How the software side works can be seen in the ECHO subroutine of the Wozmon. The programming example in the Apple-1 manual is wrong, it uses a BPL, and it won't work.