GBS-8220, 23DB Connectors and Leads

[alexh]

All Pi's have composite

[giantclam]

..ahh...found it...it is on the 3.5mm jack....cabling time... =)

[dooklink]

Originally Posted by giantclam

..ahh...found it...it is on the 3.5mm jack....cabling time... =)

So you have an A+?

[giantclam]

Originally Posted by dooklink

So you have an A+?

...apparently =) ... what's not on the workshop junkbox menu though, is a 4pole tip&ring plug...have to buy a plug & fight with it tomorrow ...

[dooklink]

I'm posting this information both on the Shmups forum and English Amiga Boards forum for those interested.

I can confirm that the Jammerboards GBS firmware will sync and display 54~55 Hz arcade games. I used GroovyMame running R-Type and Mortal Kombat to test the Jammerboards firmware at 640x480, 800x600 and 1024x768. It can be hard to get the full image on the output canvas, but it can be done. Also the default coast values need reducing and the default clamping values also need tweaking to occur during the horizontal blanking period.

What I could not get working is 50Hz PAL console resolutions. Oddly, 576i via YPbPr still worked, but not via RGBS. RGBHV is still reserved for 31kHhz+ signals and RGBS for 15kHz, which is annoying as GroovyMame is RGBHV by default.
I haven't tested 24kHz signals.

[Stedy]

@giantclam

Have you tried my required modification of adding a 680 ohm resistor on CSYNC?

Having different SDRAM vendors should not be an issue. All SDRAM types are JEDEC compliant. Providing they are the same speed grade they will be interchangeable.

Changing C11 on the GBS-8200 and 8220 from a ceramic to a tantalum will remove the majority of specks in the display.

@thread

I have Arduino Mini and Nano board here, so I can easily experiment. Have started work on some software to work in parallel with the existing firmware, just sending I2C commands to over-ride some defaults. Will be using the serial port for status info, though it could be used stand-alone.

The arduino is not my preferred platform, I use Microchip PIC products for many projects and have some good development tools. The cheap and easy availability of Arduino clones makes them a suitable alternative and loading software is comparatively easy.

Defining which registers I need to adjust and which to monitor for changes, is an interesting read The register dumps you guys provided earlier in this thread helped with some variables, like line count.

Back to coding

Ian

[giantclam]

Originally Posted by Stedy

@giantclam

Have you tried my required modification of adding a 680 ohm resistor on CSYNC?

...not initially, mainly because I have the microbee rgb daughter board insitu, but assuming nothing, I tried it anyway ; no change =)

Originally Posted by Stedy

Having different SDRAM vendors should not be an issue. All SDRAM types are JEDEC compliant. Providing they are the same speed grade they will be interchangeable.

...in the 'regulated' world, I'd totally agree -- in the knockoff world..not so much...<grin>..

Originally Posted by Stedy

Changing C11 on the GBS-8200 and 8220 from a ceramic to a tantalum will remove the majority of specks in the display.

...yeah, that was first mod off the rank ~ going by the ams1117 docs, any potential ringing should be avoided. I just started reading through the 5725 docs and checked the 'loop filter' passives are as per 'default' values - they are (both boards). I'll keep reading and then get the rpi in the picture and see what I can discover...

[giantclam]

...found a small wrinkle wrt gbs-control install script replacing /boot/config.txt with it's own custom version of same - it omits the param line 'dtparam=i2c_arm=on' which apparently is required to enable the i2c bus on the A+ (perhaps B+ too?), so simply appending the param to config.txt and rebooting gets over this hurdle...

....but on the bummer side, none of the predefined setup modes sync with ami (in fact most all of the 50Hz modes cause the monitor to complain about out-of-range...weird), and thus far no amount of twiddling seems to help any....I'll have to get my head around the register dumps and how they correlate to the tvia datasheet...

[dooklink]

Originally Posted by giantclam

...found a small wrinkle wrt gbs-control install script replacing /boot/config.txt with it's own custom version of same - it omits the param line 'dtparam=i2c_arm=on' which apparently is required to enable the i2c bus on the A+ (perhaps B+ too?), so simply appending the param to config.txt and rebooting gets over this hurdle...

....but on the bummer side, none of the predefined setup modes sync with ami (in fact most all of the 50Hz modes cause the monitor to complain about out-of-range...weird), and thus far no amount of twiddling seems to help any....I'll have to get my head around the register dumps and how they correlate to the tvia datasheet...

Rasbian keeps getting updated with new settings and I can't keep up.

With 50 Hz, most PC monitors will not accept 50Hz input. My settings specify an output and an input. Try the 800x600 modes which do 50 to 60 Hz conversion.

[giantclam]

Originally Posted by dooklink

With 50 Hz, most PC monitors will not accept 50Hz input. My settings specify an output and an input. Try the 800x600 modes which do 50 to 60 Hz conversion.

...tried to no avail ; it simply refuses to sync ..PAL or NTSC....{sigh}...no biggy tho'...still have the other gbs if I actually wanna do anything on the amiga..

[dooklink]

@giantclam

That sounds really odd. So you can't see anything on the monitor, not even the RPi menu? Or are you referring to the input of signals?

Can you detail your entire set-up, as in RPi <> GBS connections and power, output connection and monitor. Sometimes I've made assumptions as to how things are set-up. Something I've assumed to always work, be constant or set-up in the same way may not be.

[giantclam]

Originally Posted by dooklink

@giantclam

That sounds really odd. So you can't see anything on the monitor, not even the RPi menu? Or are you referring to the input of signals?

Can you detail your entire set-up, as in RPi <> GBS connections and power, output connection and monitor. Sometimes I've made assumptions as to how things are set-up. Something I've assumed to always work, be constant or set-up in the same way may not be.

...I should've been clearer ; yes I can see the rpi menu and gbs-control seems to be working as expected ; it's the amiga video I can't get to sync ; setup is as per before (and works v.good with the other gbs unit)...ie; amiga RGBHV to microbee rgb intensity board thence to gbs8200, powersupply is 9vdc (18va) regulated....it's just something with this jammaboard-touched gbs8200 at play that refuses to eat amiga...

[dooklink]

@giantclam

If the pi menu is working the issue is almost certainly the sync signal. I'm assuming you are feeding the same sync signal to both GBS boards? And that P8 is shorted when using the pi?

Also, you could try running gbs_control on the working board as that should work if the normal setup works. If that doesn't work it must be the signal. The Pi outputs 576i and can display that converted to 60Hz by default. So the gbs board must be working. The only hardware issue could be the RGBs sync input being blown, but I've yet to here of that.

You don't happen to be in Brisbane do you?

[giantclam]

Originally Posted by dooklink

@giantclam

If the pi menu is working the issue is almost certainly the sync signal. I'm assuming you are feeding the same sync signal to both GBS boards? And that P8 is shorted when using the pi?

Also, you could try running gbs_control on the working board as that should work if the normal setup works. If that doesn't work it must be the signal. The Pi outputs 576i and can display that converted to 60Hz by default. So the gbs board must be working. The only hardware issue could be the RGBs sync input being blown, but I've yet to here of that.

You don't happen to be in Brisbane do you?

....yes & yes, and that's about where my thoughts have led as well ~ 'for some reason' the unit's not doing RGBs (or if it is, it's failing to separate the H/V timing correctly) ; I've just had another poke at it and noticed that when I flip screens (F1/F2), for that moment before pi.set applies, I can see the amiga output in the way I would be expecting, but it may just be an aberration of some kind. If it isn't that, I'd suspect something in the resident fw bitbanging registers I haven't found... maybe it's been DoA since switchon =)...still, half the fun is in the searching I guess. The other gbs board doesn't suffer from any of this nonsense...

...an hour or so south of brissy actually, why do you ask?...

[dooklink]

@giantclam

Hrm, doesn't sound like anything I've seen or can explain.

I'm in Brisbane, so if you were close enough I could hookup my setup to that board and see what I can find.

[giantclam]

@dooklink

..yeah, it's really weird, and it's been like this ffrom the getgo - I'll keep poking at it for a while - if you wanna PM me your snail address, I can send it your way after I've had a sufficient fiddle....

[giantclam]

....think I got a dead one (or something weirder is afoot)... I typically choose 9dvc when given the 5-12v input option -- on a whim, moved to a 12v regulated supply - at poweron I see the blue gbs logo hit the screen, then it sits there blinking it's led on a 1, 1-2 fashion and the i2c bus comes and goes when this happens --- moved to a 6vdc supply, and it's behaving 'normally' again (and even having a better go at syncing with the amiga, although it never quite does) ; I think I call this 'errant behaviour'... =)

[dooklink]

I think 5V supplies are best. I believe higher can cause issues and maybe even damage. It depends if you have a 8220 with linear reg or 8200 with buck converter.

I was doing some testing and found some very weird behaviour. I believe I found a bug in the firmware that can get the eeprom settings stuck and the auto button stops working. I had to flash the Jammerboards firmware, set the pre and post coast values, then flash back to the original firmware to fix it. But there are still problems even then. Looks like I'll be dumping the eeprom.

[giantclam]

...m'kay...I'll get the bench supply going and feed it 5vdc ; can confirm that bug description, it's happened to me a number of times ...indeed, the board shows a prepensity to lockup when doing some mode changes (or gets things wrong) ; and as you observe, things can keep getting weirder from there on in...

edit: after some playing....best I can figure it ~ the 'S' and 'HS' inputs all tie together, presented to SOG1 (pin64) ; afaict, jammaboards all use 'VS' input as well to obtain vertical timing (VSIN1, pin45). and I have to be suspicious the jammaboard fw is mandating VSIN1 active. when in reality we want the S(C-sync) via SOG1 with H/V sync separation path...just a hunch, certainly explains what I'm seeing....

[giantclam]

Originally Posted by dooklink

....//...

I was doing some testing and found some very weird behaviour. I believe I found a bug in the firmware that can get the eeprom settings stuck and the auto button stops working. I had to flash the Jammerboards firmware, set the pre and post coast values, then flash back to the original firmware to fix it. But there are still problems even then. Looks like I'll be dumping the eeprom.

I've managed to scramble mine in similar fashion, and for the life of me I can't get the auto-scan button working again ; if you figure out how & why and work out how to get things back to baseline. plz share the wisdom =)