Predator99 wrote on 2020-06-29, 21:20:

No comment?

Just watching in awe. I don't understand the ins and outs of this, but really enjoying what you're squeezing out of this cheap gadget!

Still very impressive. However we need more experiments with different EGA cards! This is still a sampling process and I bet that other cards will have different jitter.

I just bought the same 6€ logic analyzer from china ...

I don't know anything about logic analyzers, but I'll be able to do some tests on my side if you want.

Thanks for your feedback 😉

root42 wrote on 2020-06-29, 22:55:

Still very impressive. However we need more experiments with different EGA cards! This is still a sampling process and I bet that other cards will have different jitter.

In the mean time I tested 4 EGA cards and they all behave the same...

Deksor wrote on 2020-06-29, 23:29:

I just bought the same 6€ logic analyzer from china ...

I don't know anything about logic analyzers, but I'll be able to do some tests on my side if you want.

Great...you may also like to order some of those if you dont have them already. I use them to connect the colored cable to the Monitor connector, fits very good and without loose contact.

https://www.ebay.de/itm/Straight-Right-Angle- … 872.m2749.l2649

mkarcher wrote on 2020-06-25, 15:39:

The standard VGA pixel clock for 640x480 (at 60Hz) is already 25MHz, which is above the sample rate of your analyzer.

That seems to be correct. Below screenshot is 640x480x16 "Super-EGA". Only 610 out of 640 pixels are captured. Still looks nice.

well, there's a 100Mhz analyzer available for a little over €20 ^^

imi wrote on 2020-06-30, 09:25:

well, there's a 100Mhz analyzer available for a little over €20 ^^

Is it true 100MHz? Some of the cheap ones straight out lie ...

only one way to find out I guess

root42 wrote on 2020-06-30, 09:58:

Is it true 100MHz?

Even if it's 100 MHz it does not make sense. It requires extremely powerful cpu to process this amount of data.

Today i received analyzer. On weekend i'll try to find programmers reference to make it work.

BreakPoint wrote on 2020-06-30, 13:42:

root42 wrote on 2020-06-30, 09:58:

Is it true 100MHz?

Even if it's 100 MHz it does not make sense. It requires extremely powerful cpu to process this amount of data.

why not?

it's probably limited to just 1 or 2 channels at 100Mhz and maybe 50Mhz on 4 channels like the Saleae, 100Mhz is just the maximum sampling rate.

4channels is all we need right...
or is it 6+ for EGA?

I don't think I fully grasp this yet x3

For EGA we actually need 6 channels plus 1 or 2 sync. Except if you only want to support the 200 line modes in RGBI.

EDIT: Which reminds me: does anyone have a circuit that converts RGBrgb to RGB? Then I could try to hook up my EGA to the OSSC and compare with your results.

root42 wrote on 2020-06-30, 14:14:

For EGA we actually need 6 channels plus 1 or 2 sync. Except if you only want to support the 200 line modes in RGBI.

EDIT: Which reminds me: does anyone have a circuit that converts RGBrgb to RGB? Then I could try to hook up my EGA to the OSSC and compare with your results.

https://gglabs.us/node/2063

maxtherabbit wrote on 2020-06-30, 14:35:

root42 wrote on 2020-06-30, 14:14:

For EGA we actually need 6 channels plus 1 or 2 sync. Except if you only want to support the 200 line modes in RGBI.

EDIT: Which reminds me: does anyone have a circuit that converts RGBrgb to RGB? Then I could try to hook up my EGA to the OSSC and compare with your results.

https://gglabs.us/node/2063

Ok, seems it indeed supports 6 bit RGB of the EGA. At 39 USD it's not cheap. But It has two DACs plus a bunch of other components...

It's open source so you could always just build one

root42 wrote on 2020-06-30, 14:39:

maxtherabbit wrote on 2020-06-30, 14:35:

root42 wrote on 2020-06-30, 14:14:

For EGA we actually need 6 channels plus 1 or 2 sync. Except if you only want to support the 200 line modes in RGBI.

EDIT: Which reminds me: does anyone have a circuit that converts RGBrgb to RGB? Then I could try to hook up my EGA to the OSSC and compare with your results.

https://gglabs.us/node/2063

Ok, seems it indeed supports 6 bit RGB of the EGA. At 39 USD it's not cheap. But It has two DACs plus a bunch of other components...

It says "The CGA2RGBv2 adapter will convert the TTL RGBI to analog RGB suitable to be connected directly to a 15KHz capable RGB monitor or to the popular Gonbes GBS-8200 VGA converter".
I'm not sure that modern LCD monitors support 15kHZ.

BreakPoint wrote on 2020-06-30, 14:56:

It says "The CGA2RGBv2 adapter will convert the TTL RGBI to analog RGB suitable to be connected directly to a 15KHz capable RGB monitor or to the popular Gonbes GBS-8200 VGA converter".
I'm not sure that modern LCD monitors support 15kHZ.

I have an OSSC and a bunch of 15 kHz CRTs for the Amiga. So I think this is actually a good solution for me.

BreakPoint wrote on 2020-06-30, 13:42:

root42 wrote on 2020-06-30, 09:58:

Is it true 100MHz?

Even if it's 100 MHz it does not make sense. It requires extremely powerful cpu to process this amount of data.

Today i received analyzer. On weekend i'll try to find programmers reference to make it work.

Great! I am really looking forward to see what you can do 😀

I have also noticed there are 100 MHz devices for 35€. I think I will order one and try it too. Its still much cheaper than the MCE2VGA. It will solve all problems with the jitter. With a higher sampling rate it can be easily done the way I did with the 320x200 resolution.

Yes, 100 MHz does not mean you have to use this sampling rate. The Saleae can also be used at 16 MHz, .... down to xx kHz. I think around 35 MHz would be perfect.
But more important is that somebody can access the captured data to be processed in custom software...

I made some optimizations to increase the speed. When reading from STDIN I now get around 30 fps from an image file for HGC and 16MHz sampling rate.
I reached this by switching from CSV to binary data format. Still room for improvement as from one byte only 3 bits are used for HGC. Remaining 5 bits are currently wasted.
I am currently not at home and can not test it directly from the USB device. But I think it may be a problem that its still too slow and it does not keep up with the data delivered...
I think bottleneck is not QB64 but the data transfer via STDIN...I dont know how to do it better.

For reading from STDIN to QB64 I used what is described here:
https://www.qb64.net/forum/index_topic_5380-0/
So you also need to create the "std_wrapper.h" in your QB64 directory.

I think I also need to revise my cabling. For EGA it makes sense to connect it in the order
r, g, b, R, G, B, HSYNC, VSYNC
With this you extract the color information in a very easy way from each byte read without performing any binary conversion in the program:
https://upload.wikimedia.org/wikipedia/common … 2/EGA_Table.svg

I hope BreakPoint can agree to that? ;-)

So if somebody likes to try for HGC: make sure your data from sigrok-cli is output to screen in binary format. Then redirect it to the program, e.g.:
type HGC.bin | sigrok-HGC.exe
...if data is coming from a dump file. Or...
sigrok-cli [options...] | sigrok-HGC.exe
if it comes from the USB-device.

I totally like the idea to use sigrok as data source as many different devices are supported..!

Yes, the HGC black&white screenshots I posted before can be made with this little program...

----sigrok-HGC.bas

DECLARE LIBRARY "std_wrapper"
FUNCTION getchar_stdin& ()
END DECLARE

REM Create empty screen 1000x500 pixel
SCREEN _NEWIMAGE(1000, 500, 12)

REM input one single byte from stdin to "value"
50 value = getchar_stdin&

REM read new pixel - set all previous values to 0
HSYNC = 0
VSYNC = 0
pix_color = 0

REM Read data from "value". Only 3 bits are required for HGC. If pixel is there then set its color to 15 (white)
200 IF ((value AND 8) <> 0) THEN pix_color = 15
211 IF ((value AND 2) <> 0) THEN VSYNC = 1
212 IF ((value AND 1) <> 0) THEN HSYNC = 1

REM Wait until VSYNC changes to 1: New frame begins, display time and frame-no
IF VSYNC = 0 THEN y = 0: V_REF = 1: GOTO 50
IF V_REF = 1 THEN FRAME = FRAME + 1: LOCATE 22, 1: PRINT TIME$; FRAME: V_REF = 0

REM Frame begins, display pixel. 1st 150 dots per line are junk and not displayes
230 PSET (x - 150, y), pix_color

REM Check if HSYNC is going on. If yes, go t next line (y) and set row (x) to 0. If its before x=500 it must be wrong and is ignored.
270 IF HSYNC = 1 AND x > 500 THEN y = y + 1: x = 0

280 x = x + 1

REM READ next value
700 GOTO 50

So I tested above program (sigrok-HGC.exe) with the USB device and it works really nice and nearly in real time..! Its fun looking at it!

Only problem: It only works well from an intermediate image file. When I make a data file "bintest.bin" with

sigrok-cli.exe" -d fx2laf w -O binary --config "samplerate=16 MHz" --time 30s > bintest.bin

and then transfer it to sigrok-HGC.exe using
type bintest.bin | sigrok-HGC.exe

It replays all the data captured in 30s (and the replay takes about 50s).

But when I try to do it without intermediate image file:
sigrok-cli.exe" -d fx2laf w -O binary --config "samplerate=16 MHz" --time 30s | sigrok-HGC.exe
...it stops after about 2 seconds.

When I change the samplerate to 8 MHz it runs endless (also with --continuous switch), but the picture is not that nice anymore. So still a problem with program performance / PC speed.

Currently I am very happy with my results (as I am not a good programmer) but still much room for improvenment....

So this is the current "real-time" quality at 8 MHz. Not nice, but this is really running smooth without any delay...

I think the file acts as a buffer, which could mean that without it the 16mhz sample rate is too high. Then stops due lack of input.