Atari ST discussion

[c0pperdragon]

@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]

@pixelk0 @bwmott @lopezpb

It looks like the new way of connecting works for both the ST (tested by me) and the STE (tested by aotta) but you need Beta 36: https://github.com/IanSB/RGBtoHDMI/releases (reprogram the CPLD if you tried beta 35)

[IanSB]

@aotta Could you post your calibrated saved profiles for the STE (normal and hi res mono)

[aotta]

@IanSB here's my STE profiles: Atari_STE.zip

[pixelk0]

A high res mode capture with Beta 37 I lack software ideas to test in high res. If anybody got ideas ...

[chadders2708]

Hi All Following on from the discussions above, I finally got round to seeing if I could get one of @c0pperdragon's small Denise adaptors to work on the Atari ST. I made a bunch of them some months ago and have been meaning to try this for a while. I know there is a lot of success now with the CPLD version but I love the simplicity of @c0pperdragon's design, and lets face it, you can't beat a bit of 74 series logic! :)

Anyway I'm pleased to report I have got it working rather successfully so I thought I'd share what I'd done here in case it was of any interest. Also there's a couple of things I could use some input on so maybe someone can help out.

I used an Atari 520STFM machine for this and the setup I used was very smilar to what @bwmott did above - the only real difference was the clock source I used due to the seemingly random phasing of the 8Mhz CPU clock from the MMU. I remembered from my time working on these in the 90s that the main 32Mhz clock was divided /2 by the shifter and then fed to the MMU which divides it again to give the 8Mhz clock. A quick test here seemed to point to the MMU as the source of the phasing issue so I took the original 16Mhz clock from pin 39 on the shifter and used a 74LS74 to divide it to 8Mhz.

(please forgive the crudeness of my prototyping here :) )

This seems to work perfectly and with some minor adjustments to the profile and a slight overclock of the Pi as above, I managed to get a perfectly stable image in both low and medium resolutions.

sampling=2,2,2,2,2,2,2,0,1,0,5,0,0,0,0,0,0,3,0,0,100,256,100,256,100,256,0,256 geometry=128,51,752,228,720,270,1,2,0,2,16000000,1021,7500,313,4,0,0 palette=RrGgBb_(EGA) scanline_level=0 overclock_cpu=60 overclock_core=160

The only thing was that the image was a little 'dim' and the usused bit on the adapter seemed to be picking up quite some noise so I had to ground it to clean that up. Originally I had used inputs 0,1,2 on the denise adapter which is why the image was a bit dim - moving them up to bits 1,2,3 and grounding r,g,b bit zero fixed this. Therein is the first of my questions - is there any way to get RGBtoHDMI to sample only 9 bits? In the sampling menu I seem to have no option to change it.

Also I haven't played with mono mode yet but I'd like to revert to using bits 0,1,2 for RGB and maybe bring the mono signal in on g3 - again I'm not sure how I can configure that in the profile?

@c0pperdragon - one other thing I was wondering here is if it would work if I drive the latches and Pi directly from the 16Mhz shifter clock. The clock loop on your board (if I understand correctly) is basically generating a short pulse each time the input clock changes state - thereby doubling an 8Mhz clock to 16Mhz .. that makes me think divinding the 16Mhz clock from the shifter down to 8Mhz is perhaps a little pointless if I can just run the whole show from the shifters 16Mhz output. I'll try to give this a go at some point.

Incidentally, on the subject of the clock loop, I used 74VHC86's instead of the LVCs for the clock loop on the Denise adaptors since I found this gave vastly greater noise immunity on the A600 (and even A500 [v2]) - I'm not sure how much this contributes to the success here but it might be worth mentioning for anyone wanting to replicate this.

If anyone can help with the above questions, any suggestions would be greatly appreciated

[IanSB]

@chadders2708

is there any way to get RGBtoHDMI to sample only 9 bits?

There are several 9 bit capture modes for the CPLD but to implement them in simple mode would require some software changes. For now you could short R0-R1, G0-G1, B0-B1 so that you get the full intensity range: black=0, white=15 (by grounding R0,G0,B0 you only get black=0, white=14) Also the RGB signals would have to be digitally blanked by the BLANK signal as discussed above. If you run the Closure demo you will probably see the garbage shown above. Again this could be done in software by using one of the unused RGB inputs to signal to the software that the video should be blanked like it is in CPLD mode.

Also I haven't played with mono mode yet but I'd like to revert to using bits 0,1,2 for RGB and maybe bring the mono signal in on g3

As it stands, mono mode will not work with this approach as the pixel clock is too high. The maximum usable pixel clock in simple mode is ~16 Mhz with some overclocking and the pixel clock in mono mode is ~32Mhz

The CPLD supports 12bpp @ ~16Mhz or 6bpp @ ~30Mhz or 3bpp @ ~48 Mhz or 1bpp @ ~64Mhz (pixel clock limits vary due to other settings so these are approx values). It does this using a shift register to pack the pixels into the 12 bit wide bus so two pixels are clocked in in 6bpp mode, four in 3bpp and eight in 1bpp. You could implement this in TTL but it would get a lot more complex so the CPLD would be the preferred option.

divinding the 16Mhz clock from the shifter down to 8Mhz is perhaps a little pointless if I can just run the whole show from the shifters 16Mhz output.

Both are required: 16Mhz is required to clock the latches and 8Mhz must be fed to the pixel clock input on the PI zero because it runs from both clock edges.

So I think you might be able to get this to fully work in RGB mode with appropriate software changes to add 9bpp and blanking but it wouldn't be able to support mono mode.

[c0pperdragon]

You could patch the board by lifting pin 12 of U1 and connecting this directly to GND Then the circuit could be driven with a 16Mhz clock and still produce the 8Mhz output clock signal. (There is a GND via conveniently located near pin 12 for this).

[c0pperdragon]

If you get flickering pixels this way you could use the other edge of the 16Mhz clock by connecting pin 12 to +3.3V instead (causing the XOR to work as an inverter). Or remove the solder blob on JPINV1 (there are quite some ways to get the clock signal inverted).

[chadders2708]

So I think you might be able to get this to fully work in RGB mode with appropriate software changes to add 9bpp and blanking but it wouldn't be able to support mono mode.

Thanks @IanSB .. I guess mono is out then. I confess I hadn't really thought about the clock rate there 🤦 I'll have to look into the software changes but its a while since I did any real programming.. unless you feel like making them?! 😄

I did try the Closure demo - certainly there is a little garbage at the top but I guess that's the price for hardware abuse [/sync scrolling]! In most use cases this will likely not be a problem since the hardware isn't abused to this degree - certainly this is the first time I've seen this with the software I've tested. [Though I admit I had never actually seen the Closure demo - happy to have seen it now, its rather impressive].

[chadders2708]

You could patch the board by lifting pin 12 of U1 and connecting this directly to GND Then the circuit could be driven with a 16Mhz clock and still produce the 8Mhz output clock signal. (There is a GND via conveniently located near pin 12 for this).

Thanks @c0pperdragon - I'll give this a go a bit later

If you get flickering pixels this way you could use the other edge of the 16Mhz clock by connecting pin 12 to +3.3V instead (causing the XOR to work as an inverter). Or remove the solder blob on JPINV1 (there are quite some ways to get the clock signal inverted).

I'd forgotten i had blobbed JPINV .. I think I did this when messing with the profile to see which gave the most stable results. I'll modify as above and then try with / without JPINV and see what works the best

[chadders2708]

@c0pperdragon Lifting pin 12 of U1 and grounding it made it work perfectly with the 16Mhz shifter clock. No more need for a seperate clock divider now 😃

[IanSB]

@chadders2708

I guess mono is out then. I confess I hadn't really thought about the clock rate there

You might get mono working by implementing a 2 bit shift register from a couple of D type flip flops clocked at 32 Mhz. The 2 bit output could then be fed to the remaining unused red and green bits (blue being used for 9 bit blanking) and those two bits would then be clocked in at half the pixel clock rate (i.e. using the same pixel clock as the 9 bit data).

Again this would require further software tweaking to capture the two bits and write to an appropriate display buffer.

BTW I assume you are using composite sync in simple mode so are you creating that from the H & V syncs or is it available on the STFM (I couldn't see any composite sync in the schematics I looked at)

[c0pperdragon]

It should be possible to pick up the second pixel of the mono signal with just one additional D-type flip-flop (maybe a 74LVC574 but this seems a bit of a waste for a single bit). You need to clock this with the inverted 16Mhz clock and feed the output into one of the free data pins of the board. The first pixel of the mono signal can be captured just as the regular color pixel data by another free pin. It is pretty easy to obtain the inverted clock, as the clock is fed through 2 XORs which can both be configured to do invertion (one by again adding the solder blob, the other by using 3.3V as constant input instead of GND).

A flip-flop which triggers on high-to-low transitions would be even easier to use, but these seem to be very uncommon and hard to find.

[chadders2708]

@IanSB @c0pperdragon

You might get mono working by implementing a 2 bit shift register from a couple of D type flip flops clocked at 32 Mhz. The 2 bit output could then be fed to the remaining unused red and green bits (blue being used for 9 bit blanking) and those two bits would then be clocked in at half the pixel clock rate (i.e. using the same pixel clock as the 9 bit data).

I did have half an idea for something similar bouncing round in my head so I'm glad I'm not totally off-track. My thoughts were somewhere along the lines of if I could catch the mono signal state on a 74LS74 then feed that in to the existing latches say on r3 along with the mono signal on g3 for the other bit the PI could essentially sample 2 bits simultaneously. It needs a bit more thought when I'm a lot less tired I think !

BTW I assume you are using composite sync in simple mode so are you creating that from the H & V syncs or is it available on the STFM (I couldn't see any composite sync in the schematics I looked at)

@IanSB Yes, I'm using C/SYNC. On these newer machines (small modulator box) It can normally be found on PIN2 of the MC1377P in the modulator area. Theres an XOR at U201 to the right of the shifter tin that generates it on these boards. I found a convenient spot to pick it up here on this one:

It is different for older machines though where the larger modulators are fed directly with seperate H&V sync. I'm fairly sure these don't have U201. The XOR to combine the H&V inputs is inside the modulator box.

[IanSB]

@chadders2708

It is different for older machines though where the larger modulators are fed directly with seperate H&V sync.

Yes, my STFM is like that which is why the CPLD ST profile uses separate H & V syncs (the STE profile uses composite as that is always available). I suppose composite could be picked up from inside the modulator instead but I think some of the ST models didn't have a modulator.

It is difficult to use separate H & V syncs in simple mode as Vsync is multiplexed on to the pixel clock pin. It would be preferable to generate composite sync using an XOR gate (possibly freed up from the clock circuit) on any dedicated ST design so that it allowed easy connection to all STs with 40 pin shifter.

I'll have a look at the software

[IanSB]

@chadders2708

OK here is some alpha software to test: AtariST-Alpha1.zip

This has Atari ST and STE profiles in simple mode so you will have to select the Atari ST one from the profiles line.

The samping menu now supports the following sampling modes:

1 Bit Multiplexed - mono video with adjacent pixel pairs on R3 and G3 (R3 is leftmost) clocked at half rate 9 Bits (V Sync) - 9 bits per pixel on bits 1-3 (i.e. R1, R2, R3, G1, G2, G3 B1, B2, B3) note vsync not used so same as 9 Bits (Bits 1-3) 9 Bits (Bits 0-2) - 9 bits per pixel on bits 0-2 (i.e. R0, R1, R2, G0, G1, G2, B0, B1, B2) 9 Bits (Bits 1-3) - 9 bits per pixel on bits 1-3 (i.e. R1, R2, R3, G1, G2, G3 B1, B2, B3) 12 Bits Per Pixel - uses all 12 bits R0-R3 etc as previously 9 Bits 0-2 Blanked - 9 bits per pixel on bits 0-2 (i.e. R0, R1, R2, G0, G1, G2, B0, B1, B2) with BLANKING on B3

The ST profile defaults to 9 Bits 0-2 Blanked so you will need to rewire your board to move the bits and add BLANK to B3 after which the Closure demo should work. (You can manually change the sampling mode to 9 Bits (Bits 1-3) or 12 Bits Per Pixel to check that the software still works with your existing wiring)

The mono profile defaults to the new 1 Bit Multiplexed option but this is untested as I don't have any hardware. If you connect the MONO signal to both R3 and G3 you should get a stable mono image at half horizontal resolution and if that looks OK it's probably worth experimenting with the flip flop as discussed above.

[chadders2708]

@IanSB

It is difficult to use separate H & V syncs in simple mode as Vsync is multiplexed on to the pixel clock pin. It would be preferable to generate composite sync using an XOR gate (possibly freed up from the clock circuit) on any dedicated ST design so that it allowed easy connection to all STs with 40 pin shifter.

Agreed, I was thinking to have an XOR available on the adapter to allow for more models to be supported. I know people have issues on the STF using SCART cables since there is no C/Sync on PIn 2 of the Video port. There is however a small mod to populate an area of the board to generate it. On most STFs these components were simply missing

EDIT: [The diodes go up to H & V Sync lines]

Its probably still much easier to provide a XOR on the adapter though. I have a 1040STF somewhere so I was going to dig this out and crack it open to see what's what and confirm all of this.

OK here is some alpha software to test: AtariST-Alpha1.zip .........................

Absolutely amazing sir! Thank you. 🙇

I will give it a go a bit later today and report back.

[chadders2708]

Hi @IanSB

I finally got to test it tonight and the 9-bit sampling modes work absolutely perfectly with either 1-3 and 0-2 etc. It does default back to 0-2 each time the machine is reset or powercycled though so with a 1-3 config it needs to be changed every time.

The 0-2 blanked mode does something quite strange though - it kind of goes monochrome but with a hint of blue in places:

I tried it with the blanked signal removed from B3 and that made no difference.

I tested mono mode by wiring up the mono signal to R3 / G3 as suggested and forced the machine to mono but this just gave a black screen - it did seem to detect 70Hz and it switched to 1-bit multiplexed sampling automatically but there was no display output. Forcing other sampling modes gave some kind of very distored display repeated in kind of a tiled pattern.

[IanSB]

@chadders2708

It does default back to 0-2 each time the machine is reset or powercycled though so with a 1-3 config it needs to be changed every time.

You have to use the save configuration option to keep any changes

The 0-2 blanked mode does something quite strange though - it kind of goes monochrome but with a hint of blue in places:

Is this after rewiring the signals? That mode will only work once the 9 bits have been rewired and the BLANK signal added.

[IanSB]

@chadders2708

I think I figured out the problem: The code was looking at the wrong GPIOs for B3,G3 & R3 as I forgot the CPLD rearranges the bit order in 9/12bpp mode but simple mode doesn't.

Try this version: AtariST-Alpha2.zip

[chadders2708]

@IanSB

I think I figured out the problem: The code was looking at the wrong GPIOs for B3,G3 & R3 as I forgot the CPLD rearranges the bit order in 9/12bpp mode but simple mode doesn't.

Try this version: AtariST-Alpha2.zip

That has absolutely nailed it! Thank You !! Blanking works perfectly now - no hint of any garbage in the closure demo - and in mono mode I have a stable half-horizontal resolution picture. I'll work on adding the additional latch now to catch another bit and let you know how it goes.

[chadders2708]

@IanSB I implemented the additional latch for mono mode but so far its not quite behaving as I had hoped. The R3 and G3 inputs do seem to work correctly so I don't think this is a software issue but the two pixels sampled basically seem to always be the same.

If I disconnect R3 or G3 then every alternate pixel is black which kind of confirms the software is sampling OK.

I set it up so that the additional latch is clocked directly from the 16Mhz input clock ; so it catches a pixel on the positive edge of the clock and the on-board latches on the RGB to HDMI adapter operate from an inverted clock so they esentially latch on the negative edge of the input clock which I hoped would mean would catch the next pixel.

I sketched it out quickly [JPINV is blobbed to give inverted clock in this setup]:

I'll rig up something more inline with @c0pperdragon's original suggestion to drive the additional latch from an inverted clock and the on-boards from non-inverted and see if it works any better.

[IanSB]

@chadders2708

I think your above approach is going to be sensitive to the relative propagation delays of the different logic families you are using. The other approach would be to daisy chain two flip flops (Q out of FF1 to D in of FF2) to make a two bit shift register and then clock both flip flops from the 32 Mhz clock. That would ensure that both bits were available synchronously but you might still have to experiment to get the relative phases of everything correct.

[chadders2708]

@IanSB

Agreed. I'm going to scope things out a bit so I can really see whats going on. Meanwhile, I've ordered some 74LVC74s just so I have a closer match to the on-board latches (as well as something I can drive from a 3v3 clock as an option) and will play around with different configs including the 2-bit shift register to see if I can find something that flies.

For now at least we have a great solution for most of the fun stuff in low / medium res 😄

[chadders2708]

@IanSB

The more I thought about it, the more the 2-bit shift register idea made sense so I thought I'd give it a go this evening ... and success!! 😃

The overall setup looks a bit like this :

The 32Mhz clock is taken from the top end of R75 [/pin 2 of the shifter] so currently there are 2 clocks feeding this setup. I suppose with an additional D-Type Flip Flop as a clock divider, it would be possible to drive the whole thing from the 32Mhz clock.

Anyway, I tested in all 3 resolutions and it now works perfectly in all of them.

I did note while making all the changes that setting JPINV with a blob of solder gave the best results [pin 12 of the XOR is grounded so the 16Mhz clock is inverted overall].. without this there were very occasional sparkly pixels most noticable in the dithered areas at the top of GEM desktop windows - but only in medium resolution.

I'll try to test this setup now on some other revisions of ST[F/FM) in the coming days and confirm it behaves the same.

Thanks again for your input and help with the software! I know the CPLD setup works very well but I'm happy to have another option using simple logic.

[c0pperdragon]

This looks really very nice. Still I would find the solution using just the two flanks of the 16Mhz clock a tiny bit more elegant if it is possible. You could try to feed pins 6 and 11of U1 into the two clock inputs of your extra flip-flops without cascading them but taking both their inputs from mono. Anyway the parts count is the same, you would only save a single wire from the 32Mhz clock.

Do you also plan to build an integrated PCB for you solution?

[chadders2708]

@c0pperdragon Thanks. It is nice to get to a working setup - I've been meaning to do this for some months. I can't take much credit though - the inspiration came from your orignal design and I had some great help from you and @IanSB to get it going now.

I was already thinking a bit about how I could optimise it now and have a few different options to try.

I did try something to use both flanks of the 16Mhz clock not too disimilar to your suggestion - I feed the mono signal to the extra flip flop and also to the on-board g3 latch. I clocked the extra one from pin 6 with JPINV set and pulled pin 12 high to invert the clock back to its orignal state for the on-board latches. That did work slightly better than previous attempts but was will not right:

I'll give it a try as you suggest though and let you know. Currently I'm working with TTL 74HCT74's so technically I need a 5V clock signal to drive them - I'm not sure if this was my issue. Looking at the datasheet, 3v3 signals from U1 are well above the 2v threshold for binary 1 on the 74HCTs so they should work OK I guess. I have some 74LVC74's coming so I can hopefully power and clock these from 3v3 more reliably.

Regarding PCB, I'm certinaly considering it - I was going to contact you to see if you would have any objections to me adapting your 'denise adapter small' board for this? I had thought maybe its possible to keep the same PCB size and add the additional flip-flop on the back of the board. Perhaps with a jumper on U1 pin 12 to set it up for 16 or 8Mhz input clock and perhaps one or two more jumpers as needed depending on the final setup, it might be possible to make the same board work for A600 and the ST this way?

[IanSB]

@chadders2708

I thought I'd give it a go this evening ... and success!! 😃

That's looking good but one problem is that it won't fully work with the STE models with the 84 pin shifter as they use 12bpp for low and medium res modes: The blanking signal on B3 is not required with those machines as blanking is done digitally in the 84 pin shifter but as all 12 bits are used for the RGB data there is nowhere to feed the mono signal.

This could be worked around in a couple of ways:

1. Use a digital multiplexer chip like 74157 to switch R3 & G3 from the 12 bit data to the mono data using mono detect as a switching signal
2. Use different GPIOs for the two mono bits. (All GPIOs are used in CPLD mode but some are unused in simple mode so could be used for this instead)

I think option 2 would be preferable and those alternative GPIOs could be used in standard ST mode as well. There are already two spare latches in the 74LVC574 (U3) to provide synchronous latching of the two bits to the 16 Mhz clock although it might be possible to connect those signals directly from the ouputs of the 74LVC74 instead but the state changes might not be synchronous with the pixel clock.

[c0pperdragon]

As this thread is becomming much too long already, it is continued on https://github.com/c0pperdragon/Amiga-Digital-Video/issues/56