If i got it right EhBasic, doesn't do such things. It has only a input and output address on the monitor program...

I am not familiar with EhBASIC, but I have no doubt that it can PEEK and POKE individual address bytes and twiddle the bits, and also CALL a machine-language routine. Regardless, machine-language interrupt-service routines can run underneath it without it even having to know they're there. I looked over EhBASIC years ago and could see that it was an excellent BASIC for 6502.

Ehbasic still needs some sort of putchar/getchar functions where you could do things like that.

How long does the FS* signal last on the MC6847?

The FS' signal goes low at the start of the first scan line of the bottom border of the screen and stays low until the end of the last scan line of the top border of the screen. This means it is low for the entire period when the 6847 is not accessing the video memory.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Well i still have not decided about my final design, so i would like to know how long does the signal last in microseconds(thanks for the info).

Calculation suggests the pulse should be aproximately 4,450 microseconds long, or slightly more than a quarter of the total vertical scan time.

Checking with an oscilloscope confirms that the FS' pulse is slightly less than 4.5 milliseconds wide.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Finally i got the chroma modulator from Unicorn electronics. I also had to order some other components to reach 25$, and i got some Rockwell chips!

Just don't expect a sharp picture from the modulator. Because the 6847 dot clock runs at the colour sub-carrier frequency, fine detail has colour fringes and fine patterns can appear as a block of a totally different colour.

I'm currently playing around with decoding the Y & chroma outputs using comparitors, then re-encoding the resultant logic signals to produce RGB & sync. If I'm successful, I will then be able to add a palette RAM and select which colours I have on screen.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Text modes in color is especially poor, the color graphics modes are okay though. When I switch to PAL60 on my TV I get BW which is much more crisp and clear.

I am going to experiment with taking the chroma signal from the MC1372 and feeding it to the S-Video input on my monitor to see if it turns out any better.

@PaulF, you experiments sounds interesting, will you be using some sort of CLUT/DAC device for this ?

Can i feed the composite signal output from the modulator directly to the tv input, or do i need an amplifier?

I was thinking to use 1 graphic ram, and when the cpu would like to read or write, if the fs* signal is not active, i thought about setting up some logic to set the ready signal on the 6502, so that the cpu waits for the fs* signal to go, and then it writes, reads. Can i just AND the clock phase 1 and the fs signal, or do i need more complex logic?

You are going to need an amplifier to drive your monitor. Take a look at my schematic on brielcomputer forums: http://www.brielcomputers.com/phpBB3/vi ... f=13&t=937
The MC1372 can not drive a monitor directly.

I'm sure it would be possible to create some sort of ready logic to make the processor wait for the FS* signal. This would be a massive waist of processing cycles though, where you could do other tasks instead of just waiting. I'd recommend creating some sort of interrupt driven scheme where the FS* would tell the processor to start processing video related stuff. Text is easy, it's just 512 bytes you need to worry about. The 6502 can manage scrolling and other tasks in the time that you have.

If it is real time graphics that you are going to do (like in a game) you could pre process whatever it is you are going to display in an off screen buffer, while the MC6847 is displaying an image, and when it is time to display it, simply blast it to its position during FS is low.

/Pontus

Well i could make both, if i need just to display text and wait for input, then it does not matter really if the cpu waits for the fs signal... For more advanced stuff i could make an interrupt signal...

This should be an improvement, since it means the pixels on the Y channel won't be feeding into the chroma chanel and causing colour distortion. However, with the pixel clock effectively at twice the colour subcarrier frequency, single pixels will always show poor colour - they are simply not long enougth for the colour circuits to decode them.

PAL60 is expecting a 4.433 MHz colour subcarrier, so the 3.579 MHz clock of the 6847 has no effect on the colour circuits. If you use PAL60 and clock the colour modulator at 4.433MHz you should, in theory, get a good colour display. You couldn't use the MC1372 for this, however, since it doesn't have the facility to perform the necessary phase alteration of the phaseA subcarrier on alternate lines. I might have to try this out with a pair of MC1496's - see what the results are like.



I'm decoding the Y, phaseA and phaseB signals with comparitors, then combining the results with logic to create R, G, B G* and CSYNC at logic level. (G* is a half-level G needed for orange). I then use these to drive emitter-followers that drive the analog R, G, B & SYNC signals on a SCART-equipped TV. Results so far are promising - I have decoded Y to give SYNC and VIDEO logic signals - feeding these to the G & SYNC inputs on my TV gives perfectly sharp green text & monochrome graphics on a colour display. Also, text backgrounds are true black, not the murky green the 6847 usually generates. Now I just need to decode the chroma signals & create the R, G & B signals - it should give a very sharp colour display with pure colours. I'll be posting the results when I have finalised them.

I think I'll also re-combine the TTL signals to give a composite video signal again, only this time with each colour having a different grey level. It will only be any good for a monochrome monitor though, it will still have the poor colour problem this device must have when using NTSC composite colour.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

I posted earlier that the FS pulse was about 4.4 milliseconds long and that was what I measured with a scope. However, I tried another 6847 and only got a 2 millisecond FS pulse. It started at the top of the bottom border and ended at the end of the vertical sync pulse on the composite video output.

Checking the data sheet, this is the length the FS pulse should be. It appears that the 6847 I used for the first test doesn't meet the specification for some reason. Sorry if I've misled anybody as a result of this.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!