SukkoPera's Open Source Hardware: A500/A600 Chip/Fast RAM Expansions

[SukkoPera]

It does, if it works as we intended.

I have created a project page on Hackaday where we will post further updates as testing progresses.

@Mathesar: I think you were involved in the development of the Gary adapter for PeteAU's RAM expansion board. Would you be interested in working on the next version of Raemixx? I have a few ideas but I'm not that much into the Amiga memory architecture.

[Mathesar]

Originally Posted by SukkoPera

@Mathesar: I think you were involved in the development of the Gary adapter for PeteAU's RAM expansion board. Would you be interested in working on the next version of Raemixx? I have a few ideas but I'm not that much into the Amiga memory architecture.

Yes, I contributed to the gary adapter. I am also contributing to the 14MHz accelerator here: https://eab.abime.net/showthread.php?t=97512 I might be able to help with the Raemixx. What are your ideas? More RAM Or A 68040 processor ?

[SukkoPera]

Thanks a lot. I'll get back to you after we are finished with the testing for V2. Maybe you can join the project page on hackaday in the meantime, as that should also give us some means of communication.

[Mathesar]

Originally Posted by SukkoPera

Thanks a lot. I'll get back to you after we are finished with the testing for V2. Maybe you can join the project page on hackaday in the meantime, as that should also give us some means of communication.

I love HackaDay! I'll join there in due time.

I first have to finish and release the 14MHz accelerator. Next up will be to build an SD-box (http://eab.abime.net/showthread.php?t=102642) as I can't use my internal IDE anymore once the accelerator is installed.

[SukkoPera]

Sure, take your time . SDBox works very well by the way!

[Per Hansson]

I built one with Tmtech T224162B-35J DRAM in sockets, it worked fine so you can add them to the supported DRAM list
Late edit: I also note that my A600 Rev 2D has HM514260JP8 by Hitachi so they probably would work fine too.

[katarakt]

Looks great

If somebody knows where i can find (cheap) such sockets for SOJ-42 please let me know. Seems SOJ-42 sockets are rare as hell.

[keithamiga1200]

Fantastic Have ever considered (or if it's even possible) designing the ports to be modular? The large space in the lower corner of the pcb, could possibly accommodate the different, breakaway module pcbs. Probably too much work

[Mathesar]

Originally Posted by robinsonb5

That's absolutely right, but doesn't explain why the jailbars appear in areas of solid colour. If the Amiga's video output was clean there'd be no variation in signal level over the duration of a pixel, and thus nothing to cause interference patterns.

How can you make the Amiga's video output cleaner? The single most effective way is to tie off that open unterminated clock signal on the video port. I did this on my A500's DB23-VGA adapter a few weeks ago and the jailbars are quite simply not there any more (at least in solid areas - obviously you can't eliminate pixel clock interference patterns unless your monitor's phase/pixel-clock settings are flexible enough to achieve a perfect sync.)

I have been trying your solution this weekend and it didn't work for me. So I did some investigation on the matter: It is indeed the CCK clock. But it only affects the red and green channels, not the blue channel. And, on the scope you can clearly see the interference as up and down going tiny wiggles. Up when CCK goes up, down when CCK goes down. Thus, right on the edges of the clock. This, combined with the observation that it only happens on red and green channels makes me believe it is capacitive crosstalk. Probably inside the connector as it only affects the pins that are adjacent to pin 15 (red and green).

I tried slowing the edges of the CCK down by adding some capacitance to the pin. Although it did help reducing the amplitude of the crosstalk, it also made the crosstalk a little wider e.g. lower in frequency. Thus instead of having few strong jailbars I ended up with many less strong jailbars. Also, the EMC filter on pin15 also slows the signal down a little as it contains a capacitor already.

The best solution is thus probably a series terminator resistor right after the '245 driver (u41). To be continued...

[Mathesar]

Did some more experimentation on the CCK signal. Terminating pin 15 of the video connector with a 220pF/100ohms series network ("snubber") yields the best result on my setup. Instead of some very visible jailbars (the LCD screen has to sample the "wiggle" on the green/red channels just right for the bars to become visible) I now have many/regular bars that are just barely visible.
Best solution would still be to slow down the CCK with a series termination resistor though. I haven't tried it yet as it requires modding my motherboard.
Another thing I want to have a look at is the skew between red, green and blue. I notice some colored lines near some high contrast edges and maybe we can fix those as well.

[kinmami]

Originally Posted by Mathesar

Did some more experimentation on the CCK signal. Terminating pin 15 of the video connector with a 220pF/100ohms series network ("snubber") yields the best result on my setup. Instead of some very visible jailbars (the LCD screen has to sample the "wiggle" on the green/red channels just right for the bars to become visible) I now have many/regular bars that are just barely visible.
Best solution would still be to slow down the CCK with a series termination resistor though. I haven't tried it yet as it requires modding my motherboard.
Another thing I want to have a look at is the skew between red, green and blue. I notice some colored lines near some high contrast edges and maybe we can fix those as well.

thanks, great contribution!

please let me share my findings tested with LCD and CRT

[Mathesar]

Originally Posted by kinmami

thanks, great contribution!

please let me share my findings tested with LCD and CRT

Hi, great work! I think the beads (or some other form of lowpass filtering) is essential to clean up the last bits of CCK crosstalk. They could also help with cleaning up colored edges along high contrast transitions.

However, I think there is confusion about the exact mechanism of the jailbars. "terminating an unterminated line" suggests the issue is radiation, like the CCK line acts as an antenna. Maybe it does as well but I *think* the main mechanism is capacitive coupling between the CCK line and the red and green channels. This parasitic capacitor (it's probably in the connector but it could also be on the PCB if the CCK trace runs close to the red and green trace) is very small so only fast edges of the CCK line can couple in. The 47 Ohm resistor slows down the driver so much that the edges of the CCK signal become slow enough to cause less trouble.

BTW, is that something you observed as well, than it does not occur on the blue channel? Would be interesting to know. I also checked using DPaint by creating red, green and blue screens and I could not see the jailbars on the blue screen. I could also confirm that using the scope. I will try to post some screenshots here.

PS, I'll comment here because as much as I like hackaday, I cannot really get used to *hackaday.io*

[kinmami]

Originally Posted by Mathesar

BTW, is that something you observed as well, than it does not occur on the blue channel? Would be interesting to know. I also checked using DPaint by creating red, green and blue screens and I could not see the jailbars on the blue screen.

Thanks for the feedback.
Jail bars are more intense on R and G patterns compared to B.
Displaying colour gradients from full black to full white (a complete palette set), there are few cases in which B line turns to be noisy (affected by persistent jail bars) as well.
Termination of ext clock or even better the disconnection of the unbuffered CCK solve the issue (at least on my display equipment).
The use of additional L-R (inductive-resistive) beads on RGB helps to cut High Freq noise. The C-R (capacitive-resistive) common-mode beads E431-432-433 are not so powerful at HF domain.

[Mathesar]

Originally Posted by kinmami

Thanks for the feedback.
Jail bars are more intense on R and G patterns compared to B.
Displaying colour gradients from full black to full white (a complete palette set), there are few cases in which B line turns to be noisy (affected by persistent jail bars) as well.
Termination of ext clock or even better the disconnection of the unbuffered CCK solve the issue (at least on my display equipment).
The use of additional L-R (inductive-resistive) beads on RGB helps to cut High Freq noise. The C-R (capacitive-resistive) common-mode beads E431-432-433 are not so powerful at HF domain.

So you noticed it as well? I did not do the gradient test though, maybe I should try that as well.

Although the Amiga 500 schematic suggests differently, on my system E431,432,433 are loaded with ferrite beads (L-R). However, they are indeed not very good (only "half" a winding) and on the wrong side of the parasitic capacitance. Your solution of placing them in the VGA adapter is the right place (after the DB23 connector). Also, the SMD beads you use probably have far better specs.
I agree with you about the CCK, disconnection at U41 is by far the best solution. However, it also kills compatibility with a genlock. For the RAMIXX500 it could maybe be done by a jumper? Or a small network consisting of a bead/resistor and a small capacitance right at the source which is the output of U41. That would retain compatbility with a genlock while still keeping the jailbars out of sight. At least, that is what I hope, it has to be tested first...

But as we are maximizing the video quality, shall we fix this as well:

Maybe you have seen it as well. It annoys the hell out of me. While I can accept that the image is not razor sharp because of the resampling by the LCD screen, I cannot accept these colored fringe lines.
I have found that these colored fringe lines are caused by skew between Denise's red, green, and blue channels:

What could we do about this? The delay for green is up to 4ns. Too long to compensate for by a longer trace. It might also differ among Denise versions/samples. Maybe the best solution is to resample using a 14MHz clock... Could be done on an improved vidiot or right on the motherboard.

[kinmami]

good points here in your discussion:

Originally Posted by Mathesar

I agree with you about the CCK, disconnection at U41 is by far the best solution. However, it also kills compatibility with a genlock. For the RAMIXX500 it could maybe be done by a jumper?

I suppose @SukkoPera can add a jumper to the layout.

Originally Posted by Mathesar

Or a small network consisting of a bead/resistor and a small capacitance right at the source which is the output of U41.

It could work. I was thinking (not tested yet) of inserting an L-R bead of 220ohm + 47~100pF in front of U41 pin 14.

Originally Posted by Mathesar

What could we do about this? [...] Maybe the best solution is to resample using a 14MHz clock... Could be done on an improved vidiot or right on the motherboard.

I need to think about it and see what we can do for the V3/new vidiot.

[Mathesar]

I must add that my 500 is an early rev.5 with a 8362R8. As the ramixx500 is an A500+ one would equip it with an 8373 hires Denise right? So I started digging and found one in my stash of components. So I did the test again and the skew is less on the hires Denise. About 2ns total instead of ~6ns. Visually the image quality is also better although one can still see some visible color edges. I guess it also depends on the monitor. Mine is a NEC EA231wmi. To reclock the signal for a hires Denise is not easy as you'd need a 28MHz hires clock which is not readily available.

Edit: Random thought:
Using 0,1mm wide traces and 0,1mm spacing one can fit ~0,5m of length on 1 square cm. Enough for about 2,5ns of delay.... I am going to sleep now

[kinmami]

Originally Posted by Mathesar

I must add that my 500 is an early rev.5 with a 8362R8. As the ramixx500 is an A500+ one would equip it with an 8373 hires Denise right?

Yes mainly Super Denise ECS tested

[kinmami]

Hello

I have designed and shared this adapter lately
Commodore Amiga DB23 RGB VGA External Video Buffer (V6)

it implements the THS7316 video amp for a perfect RGB equalization and filtering (100% jail bars removal).

[dalek]

Originally Posted by kinmami

Hello

I have designed and shared this adapter lately
Commodore Amiga DB23 RGB VGA External Video Buffer (V6)

it implements the THS7316 video amp for a perfect RGB equalization and filtering (100% jail bars removal).

Nice work - thanks for releasing it publically

[kinmami]

Originally Posted by dalek

Nice work - thanks for releasing it publically