VGA adapter with Blow Up and VGA/RGB switch

[trecool]

That's not good news.

[leech]

At some point in time I had a perl script that would take X11 modelines and convert them to modes in the Indivision software for the Amiga. I wonder if the same could work for generating modes in BlowUP/Videl Inside/Videlity.

[dhedberg]

Could some monitor genius please post some config settings for the 40mhz version?

These 50mhz ones don't work with 40mhz:
MS 1024 768 0 2 1216 64 128 244 790 18 772 2 1 50.000000
MS 1024 768 0 2 1216 52 140 244 790 18 772 2 4 50.000000

I don't understand monitor technology enough. I need to use 40mhz because I'm getting bus errors on 50mhz since my bus isn't accelerated.

The two modes above should work fine in Blow-Up, with a 50MHz pixel clock, and on a non-accelerated stock Falcon. At least they do so here on my Falcons.
Here's some more modes. Tweaked the previous two slightly and added a 4 color mode. So these are all 1024*768 modes for 2, 4, and 16 colors, using the 50MHz oscillator. All of them should work on non-accelerated Falcons.

MS 1024 768 0 2 1216 64 128 244 816 32 784 2 1 50.000000
MS 1024 768 0 2 1216 52 140 244 816 32 784 2 2 50.000000
MS 1024 768 0 2 1216 64 128 244 816 32 784 2 4 50.000000

[stormy]

Success!

For anyone interested, I wanted 1024x768 16 colours in Myaes and these are the settings I've used:

Daniels Blowup setting:
MS 1024 768 0 2 1216 64 128 244 816 32 784 2 4 50.000000
Myaes CNF setting:
vsetmode 26
rezmode 3

I am getting a perfect crystal clear image, non-accelerated falcon.

Badwolf: try Myaes, as I was getting a corrupted screen in xaaes as well (we must need different xaaes settings)

[stormy]

Update on my experience:

I think this hardware is very good if you need the extra screen real estate for productivity apps. But if you use your Falcon more for multi-media it's not a very good solution. I've found that even though the Falcon drops its resolution properly for demos and games etc, the bus is too swamped by the higher videl frequency that everything runs much slower. So basically games/demos/trackers become useless.
Don't get me wrong I am still thankful to Daniel for making the hardware, but I probably won't be using it unless I can find a way to accelerate my Falcons bus. I know it was pointed out at the beggining that 50hz was more suitable to accelerated bus systems, but I had no idea that the speed issues would affect lower resolutions as well.

[leech]

At least it is just a matter of disconnecting it and booting up without the prg, if you want to play a game/demo/tracker.

[trecool]

So for Mint users, Myaes/BlowUp is the way to go! Thank you!

[dhedberg]

No need to disconnect anything.

Just use the BlowUp accessory to disable the BlowUp software before starting the game/demo/tracker or any other software that is incompatible with the higher screen resolutions. An alternative is to reset the computer and boot it up without the BlowUp software. I usually do a clean boot anyways if I'm going to play a game or watch a demo.

The oscillator on the adapter card won't be used unless this is specified when setting a video mode (no software will ever do this except for resolution enhancers such as BlowUp). So again, no need to disconnect anything (not even the USB cable). If you want to turn off the oscillator for some reason you can simply use the +5V switch.

[ctirad]

At some point in time I had a perl script that would take X11 modelines and convert them to modes in the Indivision software for the Amiga. I wonder if the same could work for generating modes in BlowUP/Videl Inside/Videlity.

Sure, it could. And it would be extremely useful.
Btw, the setup lines like "1024 768 0 2 1216 52 140 244 790 18 772 2 4 50.000000" look pretty like X11 modeline.

[ctirad]

Cyprian: that's what I mean. You overclock the Videl but data bus stays the same.

MIkro, just using another pixel clock (either external or the 25Mhz VGA internal) doesn't mean the Videl is overclocked. The pixel clock is just a sync clock, that is used for generating video signals and syncs. The Videl itself still runs on its default 32MHz system clock and has still has the same speed when acces the ST-RAM.

[leech]

At some point in time I had a perl script that would take X11 modelines and convert them to modes in the Indivision software for the Amiga. I wonder if the same could work for generating modes in BlowUP/Videl Inside/Videlity.

Sure, it could. And it would be extremely useful.
Btw, the setup lines like "1024 768 0 2 1216 52 140 244 790 18 772 2 4 50.000000" look pretty like X11 modeline.

That's what I was thinking. Sadly I think I lost it in a hard drive crash. But I found it online at some point, so probably just need to try to look again.

[ctirad]

No need to finding anything, the general info about X11 modelines, overal picture generating formulas and online calculator is here: https://arachnoid.com/modelines/
All we need is only to match these constants to the constants used by Videl software (or directly to the Videl registers). The blow-up "modeline" looks like a good starting point, because it seems it uses the valid constants like X11, only in a wrong order.

[ctirad]

Here is another (more options, more suitable for us) online calculator: http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

[leech]

Nice! I believe the reason that I needed one on the Amiga was due to the way Picasso96 does things there vs how X11 does it.

[ctirad]

The picture generation rules and formulas are platform and OS independent. The Picasso is based around CIrrus logic VGA chipset originally made for PC/ISA, BTW.

[arf]

Interested, too!

[leech]

The picture generation rules and formulas are platform and OS independent. The Picasso is based around CIrrus logic VGA chipset originally made for PC/ISA, BTW.

Not really all that OS dependant. It's all based on the timing of signals. This script I had simply took whatever your current resolution was in X, and output the equivalent settings for Picasso96, which I would then input into the configuration utility and I could get perfect 1920x1080 resolution on my Radeon card plugged into my Mediator.

Don't know why we couldn't do something similar with the Falcon+BlowUP?

[Atari030]

I had a quick stab over the weekend. Not a huge amount of luck, a lot of RTFMing required I think. My main goal was to try and hit a widescreen resolution. I figure it has to be possible. Not easy, but possible. For example;

640x360
720x405
854x480
960x540
1024x576
1280x720

[ctirad]

I did a closer look to the blowup config lines and deciphered it. Lets say we have a 800x608@56Hz resolution. The blowup line looks lik this:

MS 800 608 0 2 1016 74 142 184 632 20 612 2 4 36.0000

The meaning is:

MS ; just a text
800 ; X-resolution (visible)
608 ; Y-resolution (visible)
0 ; interlace OFF (1 interlace ON)
2 ; pixel clock intput (0 - internal 25MHz, 1 - internal derived from pixel clock [32MHz on a stock F030], 2 - external
1016 ; total number of pixels on the line (visible + left blank + right blank)
74 ; left blank
142 ; right blank
184 ; hsync
632 ; total lines
20 ; upper blank
612 ; visible lines + vsync + vblank
36.000 ; 36MHz pixel clock (from external input)

[leech]

I'm going to see if I can have a play with this when I get home tonight (and the updated OIDs), since I connected a non-widescreen, multisync LCD monitor to my Falcon. We'll see how the Dell 2001FP handles me torturing it with the BlowUP. Along with the awesome work done with OIDs to separate out the fire button and use the Jag controller...

[dhedberg]

Here's something for all of you that bought the monitor adapter but didn't buy the case. Simple, but works very well.

[ctirad]

I did some experiments with botw BlowUP and Videlity software and tried to convert some suitable xorg modelines and found an interesting thing. At the first look, the constants in both Videlity nad BU look like the standard values known from the picture timing specs, but in in fact they aren't. At least not all of them. Normally a line (in either dimension) is defined (in multiples of pixel clocks) as a sum of

Code: Select all

visible area (x or y resolution) + back porch length + sync pulse lenght  + front porch lenght

In the Videl there is just the

Code: Select all

visible area + back border + front border

and that is all. So where is the sync pulse, where it is start, how it is long? Sure, there are horizontal and vertical constants to set up, but they affect neither horizontal nor vertical frequency as they should normally. WIthout a knowledge what the sync constants exactly mean, it is impossible to perform any conversion from the commonly defined video modes into Videl.

[dhedberg]

Finally found the time to finish the case for my adapter. Here's the results. If anyone's interested, the switches used can be bought from Digi-Key (part no SW332-ND) for a whopping $2 USD each.
The rubber pads can be found on E-Bay: http://www.ebay.co.uk/itm/132092960584

[mikro]

If you're still filling the queue, count me in for the next batch as well. ;)

[dhedberg]

If you're still filling the queue, count me in for the next batch as well.

PM sent.