I've added ULAPLUS Pallet support to clashbasher! :-)
It needs a bit of polishing as there is a slight delay on the pixel stream compared to the normal colours/colors. but I've tried loading up a few of the games that have pallet files on the ULAPlus web site and as far as I can tell it is working correctly colour/color wise.
I haven't tested it extensivly yet though.
I know I previously said that it wouldn't be compatable with my system due to the way I had encoded the colours/colors but I was wrong I had missunderstood how the ULAPlus pallet system worked.
Also I can only write to the pallet file but not read back yet because of the way the interface hardware is set up. Does it really need to be read/write? What I mean is if it was used on a system with an internal ULAPlus there would be a conflict if both could be read from the same port. This needs thinking about if there are going to be systems with multiple ULAPlus displays.
I can't do any more at the moment because apparently I need to go out and be sociable and get some fresh air instead of sitting infront of the b****y computer all the time :lol:
No doubt it will clash with some clone hardware but yes, I think a proper specification for a ZXI joystick standard is certainly a worthwhile thing to be discussing :)
I've added ULAPLUS Pallet support to clashbasher! :-)
Great. Now please start selling it as soon as possible!
It needs a bit of polishing as there is a slight delay on the pixel stream compared to the normal colours/colors. but I've tried loading up a few of the games that have pallet files on the ULAPlus web site and as far as I can tell it is working correctly colour/color wise.
I can only write to the pallet file but not read back yet because of the way the interface hardware is set up. Does it really need to be read/write? What I mean is if it was used on a system with an internal ULAPlus there would be a conflict if both could be read from the same port. This needs thinking about if there are going to be systems with multiple ULAPlus displays.
Read back is useful if you're doing palette cycling as you don't have to store the palette in RAM, but I don't think any software actually uses this at the moment.
Great. Now please start selling it as soon as possible!
Not to belittle the achievement, but I was really hoping for multicolour too, and 128K-like paging would be nice, given what I imagine one of these devices would cost...
At least with both of those switched on, super-accurate timing wouldn't really matter all that much.
Tell me something; this is discussing four-player controls. What's the usual way in Russia of even having a second player on a joystick? Do you use Sinclair protocol joystick interfaces?
Most of the exUSSR clones ZX Spectrum have interfaces for simultaneous connection of three joysticks. If necessary, you can easily connect the fourth joystick #FFFE, but so far this has not been necessary.
Most of the exUSSR clones ZX Spectrum have interfaces for simultaneous connection of three joysticks. If necessary, you can easily connect the fourth joystick #FFFE, but so far this has not been necessary.
Interesting... the SAM Coup? uses port #FFFE for its cursor keys and control (which would often get used as a 'fire' key). This is rather oddly overlaid with the mouse! The remaining extra keys are made available on port (rowbits?256)+249 as the high three bits (24 keys). For its built in joystick ports, it just uses the 'Sinclair 1' and 'Sinclair 2' keys, though.
Perhaps the Timex, SAM Coup?, exUSSR machines and Microdigital TK-range could all be better supported in new games? The first thing would be to better document the full range of interfaces! It'd be nice just to be able to play new Speccy games on the Coup? with one player on joystick and another on keyboard using cursor keys, for instance... or to be able to use the extra keys in user-defined key mappings.
Read back is useful if you're doing palette cycling as you don't have to store the palette in RAM, but I don't think any software actually uses this at the moment.
It didn't display that correctly and I couldn't work out why :(
Until now :-)
In a word contention. I completely missed the fact that the ULAPlus io ports are contentious. If I poke 57823,24 to change the delay in the HAM256 viewer it displays correctly.
Everything else works fine ie the pallette editor and games with new pallettes.
What to do now though?
It might be possible to fake the effects of contention via the clashbasher by using the z80 wait line or busreq but that could cause conflict with other hardware that uses these signals. and would cause problems if the clashbasher was used with a spectrum with an internal ULAplus ULA fitted ie double contention. :o
Also it would mean the clashbasher would no longer be a passive addon that just sits and monitors the signals from the spectrum.
I was really hoping for multicolour too, and 128K-like paging would be nice, given what I imagine one of these devices would cost...
At least with both of those switched on, super-accurate timing wouldn't really matter all that much.
I'm working on it. It should be straightforward to implement. The display is generated in the Parallax propeller microcontroller. The propeller has 32k of ram. The every pixel any attribute clashbasher mode takes up virtually all of that memory. However there is no reason why it can't be configured differently at start up. If you sacrifice the clashbasher mode It could be configured to do 128 style shadow screens or even the timex modes. as long as the total fits in 32K it should be possible.
8x1 attribute mode, 512x192 pixel mode, and the shadow screen from the Timex (with optional ULAplus palette). 8x1 has the bitmap at #4000 and the attributes at #6000. 512x192 mode has even columns at #4000 and odd columns at #6000. The you can run the HAM8x1 viewer and software written for the TC2048 (read port #FF to determine which mode to use). The shadow screen is just like the normal screen but at #6000. Some ideas for you to consider anyway.
It might be possible to fake the effects of contention via the clashbasher by using the z80 wait line or busreq but that could cause conflict with other hardware that uses these signals. and would cause problems if the clashbasher was used with a spectrum with an internal ULAplus ULA fitted ie double contention. :o
Given that a POKE sorts it out, I wouldn't worry about it too much.
If you sacrifice the clashbasher mode It could be configured to do 128 style shadow screens or even the timex modes. as long as the total fits in 32K it should be possible.
Enough room for the Chloe 280SE video modes? (The Timex modes in Bank 5 or Bank 7 of 128 RAM with or without ULAplus)
Yes. At one point Winston was considering building an external ULAplus for the Amstrad machines and calling it Spectra. He said as much quite a while before the other SPECTRA was released. The plug-in ULAplus should work fine on ULA-based 128s.
Well I'm working on it (well, an FPGA dev board that connects to the Spectrum, but it's one of the uses it may have), except for HDMI and it should work on all models of Spectrum since I came up with a practical clock recovery circuit a while back now to keep the ULA+ core synchronized with where the electron beam would be on a TV.
Personally I'm more interested in DVI/HDMI at the moment than VGA or SCART. My motivation is to have real hardware still usable when TVs no longer have any analogue inputs (they are already disappearing, my new TV doesn't have composite video - still has SCART, but the writing is clearly on the wall).
scart is a really old format now, and yep your right a lot of new telly's don't have it, due to what comes in to work.. you are more likely to find they composite input than scart.
scart is a really old format now, and yep your right a lot of new telly's don't have it, due to what comes in to work.. you are more likely to find they composite input than scart.
When I was looking at some new TVs a few months ago, I noticed that some have an connector and plugged in to this connector was a SCART adaptor socket.
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
When I was looking at some new TVs a few months ago, I noticed that some have an connector and plugged in to this connector was a SCART adaptor socket.
Well I'm working on it (well, an FPGA dev board that connects to the Spectrum, but it's one of the uses it may have), except for HDMI and it should work on all models of Spectrum since I came up with a practical clock recovery circuit a while back now to keep the ULA+ core synchronized with where the electron beam would be on a TV.
Personally I'm more interested in DVI/HDMI at the moment than VGA or SCART. My motivation is to have real hardware still usable when TVs no longer have any analogue inputs (they are already disappearing, my new TV doesn't have composite video - still has SCART, but the writing is clearly on the wall).
DVI/HDMI would be great! Way beyond my "teach yourself" hardware capabilities, unfortunately. :( I did search on the RS components and Farnell websites for HD video encoder chips at one stage and pulled up a few data sheets. They might as well have been written in Sanskrit for all the sense I could make of them. :confused:
Apart from its impending obselecence, another thing that bothers me about SCART is the size of the connector. I'm always slightly worried that if the cable got jolted it would yank the whole interface away from the spectrum shorting out the edge connector. Not to mention the amount of space it takes up on the circuit board. HDMI would be miles better in both these respects.
Winston, what stage are you at with your FPGA dev board? What FPGA are you planning to use. Now I have added ULA+ pallets to the clashbasher the CPLD I'm using ( an Altera MAX II EPM1270) is 96% full so I need yet a bigger device I did consider moving to a FPGA which would have advantages other than size such as PLL's and embedded RAM blocks. I've been put off by the low voltage power supply which would complicate my power supply routing. With the MAX II everything is 3.3volts so easy to route. The other thing that confused me is the configuration memory device it would need. I was looking into the Altera Cyclone series of FPGA's and the configuration devices on RS components were something like ?30! which was about twice the price of the FPGA I was looking at.
Unfortunatly the bigger size of MAX II is only available in a FBGA package so that was out. Then I saw what this guy had done. :o http://www.chiaki.cc/Pyxis2010/index.htm
So I bought the FBGA MAX II and I'm going to have a go at glueing it upside down to the board and wiring it up dead bug style. I've been practicing on an old chip I took off an old AGP graphics card.
If you get your DEV board into production it might make sense for me to migrate the clashbasher project to your board. Do you plan to have a prototyping area where I could fit a Parallax propeller chip? Will it have any extra ram in addition to whatever the FPGA your using has. If your FPGA is an Altera device it should be simple to transfer. Most of my design is in schematic capture design files with some simple state machines in VHDL. I don't know how easy it would be to transfer to a different vendors device?
I tried to copy your clock regeneration approach for the clashbasher but in the end settled for a slightly simpler approach.
it uses the inverted clock from the edge connector so when its high it holds the counter in reset then when it goes low the counter starts counting. If the spectrum is in contention the clock stays low and the counter carrys on counting and or's its result with the spectrum clock.
I then pass it through another PLL chip to get 14MHZ back to clock the Parallax propeller which generates the spectrum display. I've tested it and it syncs perfectly. when I start up the display I wait for the spectrum interupt signal to find the correct point to jump into my display loop and from then on leave it free running. I've tested it with various games such as aquaplane and bifrost and it stays in sync for as long as I leave it on (a few hours so far). I'm planning to add an alternate circuit for the 128k spectrums, which will use the 17.73447MHZ crystal I already need on the board for the AD273 PAL encoder and divide it by 20. It would be nice to be able to just use one crystal on the board for everything though.
I'm posting this as a poll as I want to judge if I'm a solo loon going on about this, or if people really are interested in either of the following Speccy devices. It seems to me we have amongst us the ability to do both quite readily:
1. A plug-in graphics card, like SPECTRA or Clashbasher, that skims off reads to the video memory into its own screen buffer and generates a SCART-compatible RGB image of its own. The difference is, this one would support the palette-switching and Timex-multicolour functions from the ULA+ specification.
So that it doesn't become redundant when we can actually get internal ULA+ upgrades, it would have the ability (typically by a hardware switch, but maybe via an OUT command) to re-map itself to skim-read from an alternative address, so that it could be used as a second or even third screen. As a minimum it should re-map to intercept reads to the ROM address space, and treat them as if written to the 16K video-accessible RAM. Better would be able to place its screen address at least on any of the first three 8K boundaries (0000h, 2000h, 4000h) allowing up to three normal screens (by stacking devices) or two multicolour screens mapped across the ROM and lower 16K address spaces. (That the ROM occasionally writes to itself is easily overcome by not using ROM routines. But note that this external video RAM is not readable).
It would probably be best if the ULA+ OUT commands that control the cards shifted accordingly, though I guess it wouldn't be a disaster if write-only port addresses were all the same, such that all cards ended up in the same mode with the same palette.
Being able to double-buffer the display (like SPECTRA can) would be a handy trick, but again, not essential as it deviates from what ULA+ will do.
A through-port is essential.
2. A 2-port joystick interface that supports IN-31 and IN-55, for adding an extra two joysticks to a setup that already has 2 Sinclair ports, such as a 128K +2, +2A, +3. Or a single port interface with a jumper/switch to select one or the other protocol.
Again, a through-port is essential.
The first is so that developers can get on and add ULA+ features to games and see the results on real hardware, instead of stumbling over a diversity of devices and varying support across emulators.
The second is so that we can start writing some serious multi-player games like other machines have (i.e. The C64, ST and Amiga have all had additional joystick inputs).
Personally, I have no specific projects which are waiting on either, though I am working on adapting a few old RAM Kempston-compatible joystick interfaces to K-55 and passing them on to developers to get things moving on that front. But the question is, is there the demand in the community? I'm sad to see new gizmos come and go without much support. And yet ULA+ seems to be something people want to support but are still waiting for. Are there things we can come together to support?
How about another option?
A 20MHz accelerator board/card like the Sam Coupe's Mayhem board from Quazar?
DVI/HDMI would be great! Way beyond my "teach yourself" hardware capabilities, unfortunately. :( I did search on the RS components and Farnell websites for HD video encoder chips at one stage and pulled up a few data sheets. They might as well have been written in Sanskrit for all the sense I could make of them. :confused:
I think it's generally better not to use those chips anyway and generate the DVI/HDMI output directly from an FPGA. The HD video encoder chips often have a lot of crap we don't care about (such as HDCP) and also require very careful PCB design because - at least the ones I've seen - consume a 24 bit *high speed* parallel input and require a high speed clock source requiring impedance control on its PCB trace, and these kind of things make it a lot less "hacker friendly". There are already simple open source HDMI encoders on the internet that can be synthesised in an FPGA and they take up very little resources.
Winston, what stage are you at with your FPGA dev board? What FPGA are you planning to use.
It's at the PCB layout stage. The FPGA dev board will be a 100mm x 100mm 4 layer PCB (the size being picked because iTead Studio do cheap 4 layer 100mm x 100mm boards!) and will have a Xilinx Spartan-6 LX9 (or LX4, either will work). The Spartan-6 directly supports HDMI/DVI signalling, and there's an open source DVI encoder already out there that'll work on a Spartan-6 (or you can do a click-through NDA and use Xilinx's DVI encoder, but I'd prefer the open source one so any resulting project can be entirely open).
The Spartan LX4 and LX9 devices are available in TQFP-144. The downside of the Spartan-6 is they don't have any voltage clamping on their inputs so the cheap and cheerful putting-of-resistors-in-series way of level shifting won't work, you need to do the level shifting properly. For flexibility I'm using a CPLD for this since it turned out to be no more expensive than using chips designed specifically as level shifters (and requires less soldering than using discrete components to do the job). I also happen to have a stock of XC9572XL (5v tolerant 3.3v CPLDs) as spares, so there's also the "it's already in the parts bin" factor to circuit design going on.
it uses the inverted clock from the edge connector so when its high it holds the counter in reset then when it goes low the counter starts counting. If the spectrum is in contention the clock stays low and the counter carrys on counting and or's its result with the spectrum clock.
I then pass it through another PLL chip to get 14MHZ back to clock the Parallax propeller which generates the spectrum display. I've tested it and it syncs perfectly.
Which is probably better for your application anyway - my clock regeneration was basically something to be done inside of an FPGA for things inside the FPGA without requiring external components or the FPGA clock management blocks (why? the minimum input frequency for the Spartan-6 onchip PLL is something like 19MHz). Well actually the clock management blocks are used but only to synthesize the some-multiple-of-3.5MHz reference clock from whatever crystal is available on the board.
I did some earlier clock regeneration tests just using a purpose designed VCO/PLL chip, but the VCO wasn't stable enough if the maximal amount of contention was happening.
Comments
I've added ULAPLUS Pallet support to clashbasher! :-)
It needs a bit of polishing as there is a slight delay on the pixel stream compared to the normal colours/colors. but I've tried loading up a few of the games that have pallet files on the ULAPlus web site and as far as I can tell it is working correctly colour/color wise.
I haven't tested it extensivly yet though.
I know I previously said that it wouldn't be compatable with my system due to the way I had encoded the colours/colors but I was wrong I had missunderstood how the ULAPlus pallet system worked.
Also I can only write to the pallet file but not read back yet because of the way the interface hardware is set up. Does it really need to be read/write? What I mean is if it was used on a system with an internal ULAPlus there would be a conflict if both could be read from the same port. This needs thinking about if there are going to be systems with multiple ULAPlus displays.
I can't do any more at the moment because apparently I need to go out and be sociable and get some fresh air instead of sitting infront of the b****y computer all the time :lol:
- IONIAN-GAMES.com -
[insert picture of Philip J Fry brandishing $100 bills here] :)
If this displays correctly then it's good enough:
http://www.worldofspectrum.org/infoseekid.cgi?id=0027262
Read back is useful if you're doing palette cycling as you don't have to store the palette in RAM, but I don't think any software actually uses this at the moment.
At least with both of those switched on, super-accurate timing wouldn't really matter all that much.
- IONIAN-GAMES.com -
Most of the exUSSR clones ZX Spectrum have interfaces for simultaneous connection of three joysticks. If necessary, you can easily connect the fourth joystick #FFFE, but so far this has not been necessary.
http://www.worldofspectrum.org/infoseekadv.cgi?what=1®exp=&yrorder=1&year=0&type=0&players=3&turns=3&memory=0&language=0&country=0&licence=0&feature=0&publi=0&release=0&format=0&scheme=0&scorder=1&score=0&have=1&also=1&sort=1&display=3&loadpics=3
Interesting... the SAM Coup? uses port #FFFE for its cursor keys and control (which would often get used as a 'fire' key). This is rather oddly overlaid with the mouse! The remaining extra keys are made available on port (rowbits?256)+249 as the high three bits (24 keys). For its built in joystick ports, it just uses the 'Sinclair 1' and 'Sinclair 2' keys, though.
Perhaps the Timex, SAM Coup?, exUSSR machines and Microdigital TK-range could all be better supported in new games? The first thing would be to better document the full range of interfaces! It'd be nice just to be able to play new Speccy games on the Coup? with one player on joystick and another on keyboard using cursor keys, for instance... or to be able to use the extra keys in user-defined key mappings.
http://fuse-emulator.sourceforge.net/
It didn't display that correctly and I couldn't work out why :(
Until now :-)
In a word contention. I completely missed the fact that the ULAPlus io ports are contentious. If I poke 57823,24 to change the delay in the HAM256 viewer it displays correctly.
Everything else works fine ie the pallette editor and games with new pallettes.
What to do now though?
It might be possible to fake the effects of contention via the clashbasher by using the z80 wait line or busreq but that could cause conflict with other hardware that uses these signals. and would cause problems if the clashbasher was used with a spectrum with an internal ULAplus ULA fitted ie double contention. :o
Also it would mean the clashbasher would no longer be a passive addon that just sits and monitors the signals from the spectrum.
I'm working on it. It should be straightforward to implement. The display is generated in the Parallax propeller microcontroller. The propeller has 32k of ram. The every pixel any attribute clashbasher mode takes up virtually all of that memory. However there is no reason why it can't be configured differently at start up. If you sacrifice the clashbasher mode It could be configured to do 128 style shadow screens or even the timex modes. as long as the total fits in 32K it should be possible.
8x1 attribute mode, 512x192 pixel mode, and the shadow screen from the Timex (with optional ULAplus palette). 8x1 has the bitmap at #4000 and the attributes at #6000. 512x192 mode has even columns at #4000 and odd columns at #6000. The you can run the HAM8x1 viewer and software written for the TC2048 (read port #FF to determine which mode to use). The shadow screen is just like the normal screen but at #6000. Some ideas for you to consider anyway.
Given that a POKE sorts it out, I wouldn't worry about it too much.
Enough room for the Chloe 280SE video modes? (The Timex modes in Bank 5 or Bank 7 of 128 RAM with or without ULAplus)
Well I'm working on it (well, an FPGA dev board that connects to the Spectrum, but it's one of the uses it may have), except for HDMI and it should work on all models of Spectrum since I came up with a practical clock recovery circuit a while back now to keep the ULA+ core synchronized with where the electron beam would be on a TV.
Personally I'm more interested in DVI/HDMI at the moment than VGA or SCART. My motivation is to have real hardware still usable when TVs no longer have any analogue inputs (they are already disappearing, my new TV doesn't have composite video - still has SCART, but the writing is clearly on the wall).
Mark
Repair Guides. Spanish Hardware site.
WoS - can't download? Info here...
former Meulie Spectrum Archive but no longer available :-(
Spectranet: the TNFS directory thread
! Standby alert !
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb!
Looking forward to summer in Somerset later in the year :)
Thats what my Samsung has!
DVI/HDMI would be great! Way beyond my "teach yourself" hardware capabilities, unfortunately. :( I did search on the RS components and Farnell websites for HD video encoder chips at one stage and pulled up a few data sheets. They might as well have been written in Sanskrit for all the sense I could make of them. :confused:
Apart from its impending obselecence, another thing that bothers me about SCART is the size of the connector. I'm always slightly worried that if the cable got jolted it would yank the whole interface away from the spectrum shorting out the edge connector. Not to mention the amount of space it takes up on the circuit board. HDMI would be miles better in both these respects.
Winston, what stage are you at with your FPGA dev board? What FPGA are you planning to use. Now I have added ULA+ pallets to the clashbasher the CPLD I'm using ( an Altera MAX II EPM1270) is 96% full so I need yet a bigger device I did consider moving to a FPGA which would have advantages other than size such as PLL's and embedded RAM blocks. I've been put off by the low voltage power supply which would complicate my power supply routing. With the MAX II everything is 3.3volts so easy to route. The other thing that confused me is the configuration memory device it would need. I was looking into the Altera Cyclone series of FPGA's and the configuration devices on RS components were something like ?30! which was about twice the price of the FPGA I was looking at.
Unfortunatly the bigger size of MAX II is only available in a FBGA package so that was out. Then I saw what this guy had done. :o
http://www.chiaki.cc/Pyxis2010/index.htm
So I bought the FBGA MAX II and I'm going to have a go at glueing it upside down to the board and wiring it up dead bug style. I've been practicing on an old chip I took off an old AGP graphics card.
If you get your DEV board into production it might make sense for me to migrate the clashbasher project to your board. Do you plan to have a prototyping area where I could fit a Parallax propeller chip? Will it have any extra ram in addition to whatever the FPGA your using has. If your FPGA is an Altera device it should be simple to transfer. Most of my design is in schematic capture design files with some simple state machines in VHDL. I don't know how easy it would be to transfer to a different vendors device?
I tried to copy your clock regeneration approach for the clashbasher but in the end settled for a slightly simpler approach.
I use a 14mhz crystal and x4 it with this PLL chip http://docs-europe.electrocomponents.com/webdocs/125d/0900766b8125d521.pdf to get 56MHZ then pass it through this circuit
it uses the inverted clock from the edge connector so when its high it holds the counter in reset then when it goes low the counter starts counting. If the spectrum is in contention the clock stays low and the counter carrys on counting and or's its result with the spectrum clock.
I then pass it through another PLL chip to get 14MHZ back to clock the Parallax propeller which generates the spectrum display. I've tested it and it syncs perfectly. when I start up the display I wait for the spectrum interupt signal to find the correct point to jump into my display loop and from then on leave it free running. I've tested it with various games such as aquaplane and bifrost and it stays in sync for as long as I leave it on (a few hours so far). I'm planning to add an alternate circuit for the 128k spectrums, which will use the 17.73447MHZ crystal I already need on the board for the AD273 PAL encoder and divide it by 20. It would be nice to be able to just use one crystal on the board for everything though.
How about another option?
A 20MHz accelerator board/card like the Sam Coupe's Mayhem board from Quazar?
I think it's generally better not to use those chips anyway and generate the DVI/HDMI output directly from an FPGA. The HD video encoder chips often have a lot of crap we don't care about (such as HDCP) and also require very careful PCB design because - at least the ones I've seen - consume a 24 bit *high speed* parallel input and require a high speed clock source requiring impedance control on its PCB trace, and these kind of things make it a lot less "hacker friendly". There are already simple open source HDMI encoders on the internet that can be synthesised in an FPGA and they take up very little resources.
It's at the PCB layout stage. The FPGA dev board will be a 100mm x 100mm 4 layer PCB (the size being picked because iTead Studio do cheap 4 layer 100mm x 100mm boards!) and will have a Xilinx Spartan-6 LX9 (or LX4, either will work). The Spartan-6 directly supports HDMI/DVI signalling, and there's an open source DVI encoder already out there that'll work on a Spartan-6 (or you can do a click-through NDA and use Xilinx's DVI encoder, but I'd prefer the open source one so any resulting project can be entirely open).
The Spartan LX4 and LX9 devices are available in TQFP-144. The downside of the Spartan-6 is they don't have any voltage clamping on their inputs so the cheap and cheerful putting-of-resistors-in-series way of level shifting won't work, you need to do the level shifting properly. For flexibility I'm using a CPLD for this since it turned out to be no more expensive than using chips designed specifically as level shifters (and requires less soldering than using discrete components to do the job). I also happen to have a stock of XC9572XL (5v tolerant 3.3v CPLDs) as spares, so there's also the "it's already in the parts bin" factor to circuit design going on.
Which is probably better for your application anyway - my clock regeneration was basically something to be done inside of an FPGA for things inside the FPGA without requiring external components or the FPGA clock management blocks (why? the minimum input frequency for the Spartan-6 onchip PLL is something like 19MHz). Well actually the clock management blocks are used but only to synthesize the some-multiple-of-3.5MHz reference clock from whatever crystal is available on the board.
I did some earlier clock regeneration tests just using a purpose designed VCO/PLL chip, but the VCO wasn't stable enough if the maximal amount of contention was happening.