c0pperdragon / Amiga-Digital-Video

Add a digital video port to vintage Amiga machines
299 stars 30 forks source link

Atari ST discussion #6

Closed c0pperdragon closed 3 years ago

c0pperdragon commented 4 years ago

@IanSB

I am creating a new thread specific for Atari ST discussions.

I don't have a (nor ever had) and ST myself, so my experience is pretty limited. But I would guess that your auto-detecing solution could be the most general solution and allows a no-hassle access to both games and professional (music?) applications.

Documentation for the video hardware is a bit hard to find, but if the Shifter is indeed a 40pin DIP, a similar solution to my Amiga board should be possible. No idea of the clearance of course and of possible case variants.

Guessing from some pictures it seems that there is an optional RF modulator next to the metal can in which the shifter sits. Removing this RF modulator (when actually installed) gives plenty of space to put the RPi just in the right spot to make the HDMI output accessible from the outside. From an adapter board with the same height profile as for the C64 and Atari 8-bit (40-pin DIP socket with long solder tails), a short 40-pin ribbon cable could go the RPi, through a slit cut in the RF shielding. When the Shifter has an additional 5mm clearance before reaching the metal shield, this should work.

IanSB commented 3 years ago

@RetroBitsAndBytes

I will be eventually.

methanoid commented 3 years ago

@RetroBitsAndBytes

I will be eventually.

For STE (pretty please) ??

ijor commented 3 years ago

Hi,

Great work! A couple of comments and recommendations:

It is not absolutely necessary to connect the HSYNC and VSYNC signals. It is possible to infer syncing from DE. This might, perhaps, fail in a couple of cases that alter syncing in the middle of the frame (not sure how the converter would handle that anyway). But implementing autosync would allow a solderless plug in into the Shifter socket.

OTOH, if you want a perfect implementation, connecting the sync signals is not enough. You have to connect BLANK as well because some demos assert BLANK in the middle of the frame intentionally.

aotta commented 3 years ago

@ianb: hi Ian, I tested the wiring with a 1024 STE, it works but not all colours are right.... i soldered R3,B3, and G3 to corresponding Shifter output, while in kicad adapter's schema they are all connected to "mono"... is that what i've to do?

IanSB commented 3 years ago

@aotta

I tested the wiring with a 1024 STE, it works but not all colours are right

The STE is 12bpp. The earlier Atari ST machines were 9bpp so on those Ataris I connected the unused R3, G3, B3 inputs to mono so that the converter could auto switch between mono and colour modes. However on the STE you should connect R3, G3, B3 to the corresponding R3, G3, B3 outputs on the STE and then change the sampling mode from 9bpp to 12bpp in the sampling menu. The converter will not be able to auto switch to mono mode on the STE.

aotta commented 3 years ago

@aotta

I tested the wiring with a 1024 STE, it works but not all colours are right

The STE is 12bpp. The earlier Atari ST machines were 9bpp so on those Ataris I connected the unused R3, G3, B3 inputs to mono so that the converter could auto switch between mono and colour modes. However on the STE you should connect R3, G3, B3 to the corresponding R3, G3, B3 outputs on the STE and then change the sampling mode from 9bpp to 12bpp in the sampling menu. The converter will not be able to auto switch to mono mode on the STE.

Thank you @IanSB ! with 12bpp sampling i get colour closer to RGB output, but still some difference... it seems to me that 16 way connector in 12 bit externder V2 is different from the one in Atari adapter schematics... is it right?

And, bigger issue, RGBtoHDMI switch to the Mono subprofile, but only black screen. STE needs a different profile?

IanSB commented 3 years ago

@aotta

it seems to me that 16 way connector in 12 bit externder V2 is different from the one in Atari adapter schematics... is it right?

The Atari adapter matches the V2 12 bit extender but the V1 12 bit extender has a slightly different pinout on the 16 way for pins 2, 3 & 4 (I think you had some V1 boards made before I posted the V2)

On V1 12 bit extender Pin2 = B0 Pin3 = G1 Pin4 = R0

On V2 12 bit extender Pin2 = R0 Pin3 = B0 Pin4 = G1

And, bigger issue, RGBtoHDMI switch to the Mono subprofile, but only black screen. STE needs a different profile?

Mono mode won't work with the STE unless you make up a separate cable because there are no spare inputs to connect the mono signal. You could make up a separate cable for mono mode that plugs into the Atari video connector as the sync and mono signals are TTL levels (connect mono to G3).

aotta commented 3 years ago

@IanSB thanks Ian, you was right (as always), my adapter is an issue 1! i used it in the STFM and didn't notice the wrong colours.. I'll try to swap the pin 2-4, and adding a switch to mono->G3 and mono-detect->GND, and i'll report if it will work fine.

aotta commented 3 years ago

Mono_Res Medium_RGB I can confirm that a switch for Mono/G3 works fine, with autoswitching subprofile too!

methanoid commented 3 years ago

Thanks @aotta for confirming it works... Are you recording somewhere what you did exactly and what connections to where.. doesnt look like same board I see for Amiga (obviously) so no idea where to source the board!

aotta commented 3 years ago

@methanoid , i didn't record the single steps, but i simply solder separately each wire of the 16 IDC cable following the STE schematic: wirig the 12 bits color to R0-3,G-3,B0-3, Vsync and Hsync to the two resistor near L404 and L405 (i can't remember the resistors' code, but in my STE they wasn't the R435 and R437 showed in schematic), and +5V and GND in the opposite sides of C412: Wiring for the "Mono" output, as reported above, i added a switch to select connection to R416 or R430 and G3 wire (and shorting pin 1 and 14 in the video connector for forcing STE to Hires). That's all, but i'll try to help you if you need more info.

lopezpb commented 3 years ago

I have assembled RGBtoHDMI set for Atari ST but unfortunately there is a problem after starting the computer, it displays the message "no sync detected" and the image flashes (automatically selects the profile for Amstrad_CPC), only restart rpi0 or a few restarts helps, after that it selects the Atari ST profile. IMHO Vsync and Hsync are correctly connected to the pin 4 and 5 RF modulator.

ST_RGBtoHDMI

I recorded video with the problem: https://www.youtube.com/watch?v=wk3WJtIX_Uk

Everything works fine, when I copy the Atari_ST profile to the / Profiles / 6-12_BIT_RGB_Analog folder and after start, select it.

https://youtu.be/MgbGX0Sxb2E

Additionally I did tests:

Vsync and Hsync signal is on 12 Bit Board, do you have any advice, what else can you check?

Although everything seems to work fine as an analog, either there is a software bug or I am doing something wrong.

ps. I'm sorry for my english.

IanSB commented 3 years ago

@lopezpb

The problem is that your board is falsely detecting that an analog board is fitted and switching to the analog profile set.

Detection of the analog board is made by looking at the P19 (DETECT) line on pin 1 of P5. This is pulled low by one of the 4.7K resistors in the SIL resistor network RN3 and the analog board when fitted pulls this high using a 1K resistor thus indicating that an analog board is connected.

For some reason that line P19 is reading high so there may be a short connected to that line.

You need to check around pin 1 of P5 and also pin 19 of the CPLD as it may be shorted to pin 18 or 20

Try connecting a voltmeter or oscilloscope to P19 to see what level it is at (It should be 0V)

Also you need to change the picture size setting on your TV as it is zooming in by 5% and cropping part of the menu.

lopezpb commented 3 years ago

I have checked, there are no short between pins 18/19/20 on CLDP.

On P19 is 8MHz signal

P19M

P19CLDPM

scopeM

IanSB commented 3 years ago

@lopezpb

On P19 is 8MHz signal

That's definitely wrong and looks like the PSYNC signal which is on pin 22 of the CPLD (last pin on that row of pins) so check for a short between pin 19 and pin 22.

Check that resistor network RN3 is fitted the right way, the pin 1 "dot" on the package should be close to SW3

Also look at the signal on the "DAT" pin of P5 with your oscilloscope as that line can affect the state of P19

EDIT: also check any of the other unused pins on P5 (M7, Mux, DAT, CLK, STB) for the 8 Mhz signal

lopezpb commented 3 years ago

That's definitely wrong and looks like the PSYNC signal which is on pin 22 of the CPLD (last pin on that row of pins) so check for a short between pin 19 and pin 22.

Signal on pin 19 and 22 are the same but there are no short

Check that resistor network RN3 is fitted the right way, the pin 1 "dot" on the package should be close to SW3

It's ok I've checked it

Also look at the signal on the "DAT" pin of P5 with your oscilloscope as that line can affect the state of P19

No, signal on DAT is quite different

EDIT: also check any of the other unused pins on P5 (M7, Mux, DAT, CLK, STB) for the 8 Mhz signal

I've checked all board and 8MHz signal is on pin 19/22 CLDP, GPIO17_psync, P19 and 6 pin of resistor network.

aotta commented 3 years ago

@lopezpb are you sure you got good hsync & vsync? Did you checked them with scope? In some motherboard without modulator (like mine) you have to get them elsewhere

lopezpb commented 3 years ago

@aotta Yes, it's the same signal as on GLUE chip (Hsync pin 37 and Vsync pin 38)

IanSB commented 3 years ago

@lopezpb

Actually thinking about it, the 8Mhz can appear on P19 under certain circumstances so that might be OK

One other way for the board to be incorrectly identified is for one of the 12 bits going from the CPLD to the Pi Zero to not be connected: (These 12 bits normally send the video data to the Pi but also send the version number of the CPLD and the top bit indicates analog or digital interface.

Check that the following two pins are connected: Pin 1 of the CPLD to Pin 33 of the Pi zero

Also you mention above that you tried on two RGBtoHDMI boards but do you have two Pi zeros as well? If not, try another Pi zero as a faulty Pi zero was the problem with another issue recently with one GPIO bit stuck at 0v

EDIT: Also check that pin 1 of RN3 is connected to ground

lopezpb commented 3 years ago

I checked with another Rpi0 - no changes. I put together the third RGBtoHDMI set and it behaves exactly the same. I have traced all the connections according to the diagram: https://raw.githack.com/hoglet67/RGBtoHDMI/dev/Kicad_6Bit/v4/rgb-to-hdmi.pdf and everything looks fine.

Also check that pin 1 of RN3 is connected to ground

Yes it is.

I have no ideas what else to check, maybe purchased CLDP are damaged in some way? but they program without problems and it is unlikely that three different chips are damaged in the same way, although they are from the same supplier.

lopezpb commented 3 years ago

I think I found my mistake, I have resistor network 4606X-102-472LF instead 4606X-101-472LF. 472LF

IanSB commented 3 years ago

@lopezpb

I think I found my mistake, I have resistor network 4606X-102-472LF instead 4606X-101-472LF

Yes that would cause the problem as the P19 detect line wouldn't be pulled low, instead it would be connected to the B0 line.

EDIT: B0, not DAT

IanSB commented 3 years ago

@lopezpb

To test this you can remove the resistor pack and put a single 4.7K resistor between pins 1 and 6 of RN3 (any value from 1K up to about 47 K should work for a temporary test). The other pins of RN3 on R0,G0,B0,G1 don't really need the pull downs as they are connected to valid signals anyway for the Atari ST (Same for RN1 & RN2).

lopezpb commented 3 years ago

I used 5 x 4.7K resistors, now everything works fine. I ordered 4606X-101-472LF but I have to wait 6 weeks for them.

Thank you IanSB for your help!.

lopezpb commented 3 years ago

Back to the Atari STE version, I think it could be make like in a board for the Xtraram extensions with pins plugged into the SGT Shifter, from what I can see all the necessary signals are in one row.

Xtra-ram pcb: xtraram

GST Shifter gst-shifter

lopezpb commented 3 years ago

Since I had a few requests to show how it looks in action, below is a video with a demo run and mono mode on RGBtoHDMI with full screen scaling.

Atari 520ST 2MB, CT'ide + RGBtoHDMI

https://youtu.be/feqQMbEpsVg

bfollowell commented 3 years ago

It looks really good. It’s a beautiful, crystal clear image. Personally though, I despise stretched screens. Is there anyway to maintain the original aspect ratio, or is that taken care of in the display settings?

Thanks for the video.

On Mon, Jun 7, 2021 at 3:25 AM lopezpb @.***> wrote:

Since I had a few requests to show how it looks in action, below is a video with a demo run and mono mode on RGBtoHDMI with full screen scaling.

Atari 520ST 2MB, CT'ide + RGBtoHDMI

https://youtu.be/feqQMbEpsVg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6#issuecomment-855717638, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOUCGL4ZE43RYDV3CM3V7LTRR7ADANCNFSM4Q57XM3A .

-- Sent from Gmail Mobile

lopezpb commented 3 years ago

Of course you can set different screen aspect ratio settings such as e.a. 4:3. I will try to get a video with different settings, although I don't know if the mobile phone will catch diferences with soft and softer.

"A number of options are available: Auto Integer / Sharp Integer / Soft Integer / Softer Interpolate 4:3 / Soft Interpolate 4:3 / Softer Interpolate Full / Soft Interpolate Full / Softer"

bfollowell commented 3 years ago

No need to post another video, unless you just want to. I appreciate it though. It just seems that most of the videos and images I've seen show a stretched desktop, so I'd started to wonder if the aspect ratio was locked at 16:9. Thanks for the video and the information.

On Mon, Jun 7, 2021 at 5:10 AM lopezpb @.***> wrote:

Of course you can set different screen aspect ratio settings such as e.a. 4:3. I will try to get a video with different settings, although I don't know if the mobile phone will catch diferences with soft and softer.

"A number of options are available: Auto Integer / Sharp Integer / Soft Integer / Softer Interpolate 4:3 / Soft Interpolate 4:3 / Softer Interpolate Full / Soft Interpolate Full / Softer"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6#issuecomment-855798084, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOUCGKTN6EPFFVSDN5FE7DTRSLKRANCNFSM4Q57XM3A .

pixelk0 commented 3 years ago

Just made my 5 RGB2HDMI and order the PCBs for 5 12bit extenders and 5 ST buffered board (I only need 2, but minimum batch sizes and orders...). Is there a reason for the discrepancy in the Capacitor footprints between the main board ( 0805 100nF ) and buffer board ( 0603 100nF ) as I had to order two batches to satisfy the different part sizes ? The Atari ST boards and connections lack a Wiki page and I had to dig a bit to gather the informations. I'm not complaining and am very glad that such a solution exists and is available (by the way, thank you for your incredible work !), I just want to offer to help to create the "missing" wiki page if you think it's a valid idea. By the way, would those long pins (initially for wire-wrapping) be adequate for the buffer board ? https://www.ebay.com/itm/180598510456 --EDIT on 2021-06-23 -- Just realized as I've got an STE, the buffer boards will be useless to me :/ I also found this more clear diagram of the output circuitry here : https://info-coach.fr/atari/hardware/video.php

video-schematic-blackbg

IanSB commented 3 years ago

@pixelk0 Sorry I haven't added any wiki info for the ST yet. As you noted the buffer board is for the ST and you will have to manually solder the cable from the 16 way 12 bit extender board to the RxGxBx lines coming from the video chip on the STE. It's probably easier to solder to the video chip side of the resistors in the DAC.

The pinout of the 16 way connector can be found in the cables section of the wiki: https://github.com/hoglet67/RGBtoHDMI/wiki/Cables

If you use a 2 pole changeover switch you can solder one pole to switch either G3 or MONO from the video chip to be connected to G3 on the RGBtoHDMI and the other pole can be used to ground the auto detect mono input when the MONO signal is connected to RGBtoHDMI so that mono hires works as well.

pixelk0 commented 3 years ago

Thank you. I couldn't wait and soldered directly my ribbon (a snip from a SCSI 50 ribbon) from the source resistors to the pin on the 12bit board issue 4, where I soldered the pull-up resistors on the top to get more space underneath. I initially inverted H-Sync and V-Sync which resulted in no sync at all of course.

20210625172535

I didn't solder the monochrome pin as I have no real use for the high res mode yet and I can display it directly in VGA. I soldered my power pins (+5V and GND) on C413

STe_DAC

My V & H-Sync

STE_Sync

--- EDIT ---

After correcting the sync swap, I have a clearer image, but not fully. The picture is constantly wobbly.

20210625222515

https://user-images.githubusercontent.com/5732483/123481618-4887ba80-d604-11eb-8459-5ecd0309e5fb.MP4

I'll read the rest of the wiki to see if I find how I can try to tweak it. but so far it's better than any analog output I ever got. Thank you !

--- EDIT 2 ---

The wobble stopped in low res without any conscious action but a reboot. It persists in mid res. And for further reference, on my 520 STE Mainboard, my soldering points :

STE_RGB_DAC-SYNC

--- EDIT 3 ---

After a successfull auto calibration, the screen wobble is gone, in low and medium res. GREAT SUCCESS. I tried Spectrum 512, and Photochrome with a TGA picture and it displays flawlessly.

20210626131633

20210626195419

--- EDIT 4 ---

More and more people (in Atari-Forum ) want to buy the surplus boards from me, how can I pay back to this project ? I don't want to profit from your work.

IanSB commented 3 years ago

@pixelk0

More and more people (in Atari-Forum ) want to buy the surplus boards from me, how can I pay back to this project ? I don't want to profit from your work.

Maybe I'll set up a donation page or something.

The main reason I haven't documented the Atari connection yet is that I want to investigate an alternative way of connecting the sync signals. It has been suggested that I use the DE signal as a substitute sync source instead which would make the basic ST upgrade entirely plugin and leave the vsync input free to be optionally connected to the blank input which is currently ignored. I undestand that some demos assert the blank signal during active video and that would have no effect at the moment.

Also the sampling phase (in the sampling menu) will have to be set to a compromise value manually rather than running an auto calibrate because of the problem with the sync signals randomly shifting 180 degrees with respect to the pixels on power up.

BTW on you STE the crystal is 32.084998Mhz which means a pixel clock of 16.042499Mhz. My ST uses a 32Mhz crystal / 16Mhz pixel clock. Is that normal for all STEs and is there a reason for the difference?

EDIT: The DE / blank suggestion was made by @ijor above in this thread

EDIT2: It looks like the Closure by Sync demo posted above by @bwmott shows the problem of ignoring the BLANK signal as there a a few lines of garbage at the top of the screen.

pixelk0 commented 3 years ago

Just redid a capture and the Pixel Clock is now captured at 16042513 Hz from RGB2HDMI source page PAL French 520STe

Clock_NoEXIF

According to the STe schematics, it is the good value for U402 :

U402

I captured Closure (before correcting the colour bits, but that should only affect... colours.

With RGB2HDMI https://youtu.be/H2aNV49jq9s And a SCART2HDMI https://youtu.be/OiSwB3mTZGs

IanSB commented 3 years ago

@pixelk0

I captured Closure (before correcting the colour bits, but that should only affect... colours.

Looking at the STE schematic, the 84 pin shifter chip has a BLANK input so it is doing the blanking internally in the chip and should work correctly.

On my ST the 40 pin shifter chip doesn't have a BLANK input and blanking is done by an external analog circuit after the DAC so RGBtoHDMI needs the BLANK signal only on systems with the 40 pin shifter. If you look at your version of Closure and compare to @bwmott 's screencap above, your version shows black at the top and his shows garbage (running on a 40 pin shifter). See: https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6#issuecomment-792336841

As it's only required for the 40 pin chip I could implement that functionality on the pickup board by using the buffer chips to force the 12 bits to zero when blanking is active. The alternative would be to implement blanking in the CPLD and feed the blank signal in on the VSYNC input but that would mean using composite sync or maybe the DE signal on the HSYNC input. Composite sync isn't available on the ST so will have to be made by ORing the two signals together.

I'm not sure if there is enough space in the CPLD to implement blanking but I will try that first.

I haven't investigated the use of the DE signal suggested by @ijor yet.

IanSB commented 3 years ago

@pixelk0

I've fixed the blanking problem with a CPLD and software update plus a small mod to the pickup board: Before the fix: capture3 capture5

After the fix: capture14 capture23

As this only affects the 9 bit per pixel RGB output on the 40 pin shifter I used one of the unused bits (B3) on the 12 bit input so no changes were needed to the existing H and V sync inputs. (G3 is used for the mono input and R3 is still unused). The mod requires the track going between B3 and G3 to be cut on the pickup board and then a wire soldered from B3 (Pin 15 of header) to the !BLANK signal.

IanSB commented 3 years ago

@bwmott @lopezpb

I have updated the software and CPLD to fix the blanking problem on the Atari ST (see above screencaps): Download the latest beta (currently beta35): https://github.com/IanSB/RGBtoHDMI/releases (Wipe the SD card and install the new files). You must update the RGB CPLD to the latest version (v94)

You must also make the following modification (output will be not be visible until the mod is made): On the underside of the 40 pin shifter pickup board cut the track going to pin 15 of the header (B3): pickup_mod_b3 Solder a wire from Pin 15 to the BLANK signal from Glue pin 36 This signal is also on three diodes near the shifter (see ST schematic)

IanSB commented 3 years ago

@aotta @pixelk0 I have changed the way that the STE is connected so that the mono signal doesn't need to be switched and it now works in a similar way to the ST. Please download beta 35 as above: https://github.com/IanSB/RGBtoHDMI/releases (Wipe the SD card and install the new files). You must update the RGB CPLD to the latest version (v94)

You must also make the following changes to the STE connection: Connect composite sync to the HSYNC input of RGBtoHDMI (Wire 12) Composite sync should be available on U211C pin 6 (74LS04) also on U403 (MC1377) Pin 2 (See STE Schematic) Connect MONO to the VSYNC input of RGBtoHDMI (Wire 14)

After these changes, the mono video will automatically be selected when the mono sense input is grounded on the STE video connector just like the ST. You can test this by inserting a low value resistor or wire link between pins 4 and 13 of the video socket.

I have also updated the cables page with the new ST and STE connections: https://github.com/hoglet67/RGBtoHDMI/wiki/Cables

Can you test that this works OK as I don't have an STE

aotta commented 3 years ago

@ianSB: new wiring and sw for STE works, but i got some dirty lines with monochrome's setting: capture10

I don't know if it's a poor cabling from mine, or some setting to tune better... any hints?

IanSB commented 3 years ago

@aotta

How long is your ribbon cable?

It might be crosstalk on the cabling or noise in the composite sync but try the following:

Connect the composite sync pickup point to the inverted composite sync signal which is on pin 5 of U211C (same 74LS04). This signal is also on Pin 3 of U209 (74LS86)

You will have to change the Sync setting in the Geometry menu from "composite" to "inverted" (Twice, for both the normal sub-profile and the mono sub-profile)

aotta commented 3 years ago

Ian, no difference with inverted comp from pin 5... the strange thing it's that it starts fine, and garbage appears after a minute and stays

aotta commented 3 years ago

... and auto calibrate, sometimes finishes with a blank screen. With previous cabling and software, i had no issue at all

aotta commented 3 years ago

@IanSB i think the issue is in the auto calibrate routines... if i manually set sampling to phase=1 and pixel h offset to 7, i get a clear screen with no garbage!

IanSB commented 3 years ago

@aotta

i think the issue is in the auto calibrate routines... if i manually set sampling to phase=1 and pixel h offset to 7, i get a clear screen with no garbage!

OK thanks it looks like there is a bug in the sampling phase code as you can set the phase from 0-5 in x4 mode and it should only set from 0-3. I'll fix that and upload a new beta to try soon

aotta commented 3 years ago

@IanSB thank you, in the meanwhile, it works fine with the setting manually changed, even with sampling phase 0! Waiting for beta 36!

IanSB commented 3 years ago

@aotta

Beta 36 is uploaded, I hope this one is OK!

NOTE: You MUST reprogram your CPLD if you used Beta 35

aotta commented 3 years ago

@IanSB you made your homework well! ;) now auto calibrating works flawless, thank you!

aotta commented 3 years ago

now i can switch "on the fly" from mono to colour ouput only changing setting with my homemade tool! ;) stemonoswitch

IanSB commented 3 years ago

@aotta

now auto calibrating works flawless

Thanks for testing, this will now be the official way to connect the STE.

now i can switch "on the fly" from mono to colour ouput only changing setting with my homemade tool! ;

I'll have to make one of those (just orderd an ST video plug). I'm currently poking a wire into the video socket on my STFM!

Perhaps you could look at Apple IIGS when possible as there may still be some issues: Current discussion here: https://github.com/hoglet67/RGBtoHDMI/issues/209

BTW is your IIGS NTSC or PAL?

aotta commented 3 years ago

Thanks @IanSB , i missed the discussion here, but i had in list the IIgs testing since red about it on stardot's forum. But the STE was under my bed, the IIgs is on top of the wardrobe, and i'll have to find the ladder! ;) And, i'm not sure if mine is PAL or NTSC, since i remember had to mod the psu from 110v to 220v, but i use a scart adapter with my tv and it works fine.... i'll check it and will report the progress