SPECTRA New from Paul Farrow

edited April 2013 in Sinclair Miscellaneous
Looks good! Read about it here
Post edited by Macc on
«13

Comments

  • edited August 2012
    Macc wrote: »
    Looks good! Read about it here

    Please tell me this got implemented according to the ULAplus spec and not some completely new and incompatible scheme.

    Edit: Ok. I've read the document. It's a real shame Paul didn't implement ULAplus. I can see a number of problems with SPECTRA already, not least the choice of I/O ports[1], but I'll be the first to admit that from an engineering point of view it's a neat solution. It will be interesting to see whether emulator authors have any interest in supporting it. If they do then ULAplus is probably dead, which is a shame as it's a much better solution. But then I would say that wouldn't I.
  • edited August 2012
    As far as I understand, it's a completely different scheme, sadly.
  • edited August 2012
    na_th_an wrote: »
    As far as I understand, it's a completely different scheme, sadly.

    Yes it is, and it lacks the main advantage of ULAplus. Any existing software will need to be rewritten to take advantage of the extra colours in SPECTRA. I think it's a missed opportunity.
  • edited August 2012
    Exactly my thoughts.

    Besides, I prefer the ULAPlus approach (using redefinable palettes). Spectra seems to encode all colour information in the attribute file.
  • edited August 2012
    na_th_an wrote: »
    Exactly my thoughts.

    Besides, I prefer the ULAPlus approach (using redefinable palettes). Spectra seems to encode all colour information in the attribute file.

    The benefit of doing it that way is you don't need 64 external registers to store the palette state. Having said that this thing is using 16K of SRAM to mirror the VRAM, so I don't suppose another 64 bytes would make a huge difference.
  • edited August 2012
    I see a number of issues with this device:
    - It's based upon a 5V FPGA which is no longer available, and lacks from some advantages that modern (Spartan 3E/3A/6A) FPGA's have, such as enough internal block RAM so you don't need a external SRAM chip.
    - It main purpose is not to offer a wide range of colours. That, I think, it's a "side effect". Its main purpose is to mimic screen contents to output them in RGB mode to improve picture quality. This is something that Winston talked about some time ago, but his idea was to use a line-size double buffer to output the picture to a VGA monitor.
    - To accomplish that, it has to synchronize with the video output, and this is where its main issue is located: it uses a signal that is present only in 48K models. So this device won't work (off the shelf) with anything other than a rubber key/Plus model. Not even the brand new Harlequin clone will be able to use it.
    - Its main advantage is that you don't have to open your computer to use it... unless you have a issue 2 model (some revisions) which forgot to put a jumper in the /Y signal, which is the one this device uses to synxhronize with the Spectrum.
    - It is not compatible with the ULAPlus specification. If you are going to offer new colours, palettes and so on, why not adhere to something that it's beginning to gain acceptation, such as the ULAPlus?
  • edited August 2012
    well its in an FPGA, so the soft-core could be adapted for ULA plus with a re-write.

    an interesting method of scan doubling to RGB out - saving on components and noise when using discrete components, and its interesting to have another 12 screen modes...

    I am impressed and intrigued, it would be good to see adaptations of these or even a ULA plus version of it.
  • edited August 2012
    Most interesting.
    I didn't know that it is even possible.
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited August 2012
    Zetr0 wrote: »
    its interesting to have another 12 screen modes

    There's a novelty factor I suppose, but without software they aren't much use and any mode that uses more main RAM than the standard screen won't work with existing software. That's why I had to use bank 7 on a Spectrum SE to implement 80 column mode in SE BASIC.
  • edited August 2012
    I was interested up to the point where it became clear that even though it can store two completely independent screens at the highest colour detail, it can't display one whilst the other is being re-written. So it's incapable of double-buffering the enhanced colour screens.

    The only screens it can buffer and display independently are two ordinary 6.75K screens, and the 128K Spectrum can already do that.

    I can't see many game developers taking an interest in any of the enhanced modes - it means you have to update twice as much graphics data, with nothing to stop the screen flickering as you do so. Bit of a missed opportunity.
    Joefish
    - IONIAN-GAMES.com -
  • edited August 2012
    Well, I want one. It looks as though it does a grand job/s, but again... I think I'm actually a lil cross about no ULAplus support. Tsk! Will we ever get easy plug-in hardware for this?
  • edited August 2012
    You all say its a missed oppotunity can none of you contact Paul and see if things can be redeveloped ??????
  • edited August 2012
    Graz wrote: »
    Well, I want one. It looks as though it does a grand job/s, but again... I think I'm actually a lil cross about no ULAplus support. Tsk! Will we ever get easy plug-in hardware for this?

    As a proof of concept it shows that ULAplus could be done as an external plug-in. The basic idea is that you mirror the video RAM and then use your own video hardware to generate an image from that. I think it might be possible to reprogram the device to support ULAplus, but as has been pointed out, it currently relies on edge connector lines that are only present on the 16K and 48K models.
  • edited August 2012
    You all say its a missed oppotunity can none of you contact Paul and see if things can be redeveloped ??????

    I already contacted him. Haven't heard back yet. Hopefully it's possible to adapt the board to support ULAplus by reprogramming the FPGA without having to make any other modifications.
  • edited August 2012
    it's a really nice idea, but I don't know if I'd use the additional resolutions without some tools to utilise it for games

    thing is with ULAplus it's just a simple matter of detecting and loading an alternative palette, which is what started me on the 'road' (pun intended) with this. As soon as the idea popped in my head I knew that ULAplus would be the only way to do the game justice (it's just at the initial design stage at the moment) at least to get a proper tarmac sort of colour.

    demo bridge2.png

    Or I'll design two sets of blocks, one standard colours, and a second set to take advantage of the enhanced palette, but again I can see it only needing a minor modification of some of the bitmaps and the colours, two game versions - doddle

    I don't want to poo poo Pauls work I think it's an amazing idea and I'd certainly like to see what it can do, just wish I could plug the ULAplus in a machine right now!!
  • edited August 2012
    BiNMaN wrote: »
    it's a really nice idea, but I don't know if I'd use the additional resolutions without some tools to utilise it for games

    thing is with ULAplus it's just a simple matter of detecting and loading an alternative palette, which is what started me on the 'road' (pun intended) with this. As soon as the idea popped in my head I knew that ULAplus would be the only way to do the game justice (it's just at the initial design stage at the moment) at least to get a proper tarmac sort of colour.

    demo bridge2.png

    I like it!
    Or I'll design two sets of blocks, one standard colours, and a second set to take advantage of the enhanced palette, but again I can see it only needing a minor modification of some of the bitmaps and the colours, doddle

    I'd suggest having two different sets and loading the appropriate one based on whether ULAplus is detected or not. If you don't modify the bitmap at all you could store an alternate attribute set. Whatever you do, I hope you'll use all four CLUTs. Aside from the HAM256 viewer I'm not aware of any ULAplus software that uses more than 32 colours on screen at once.
    I don't want to poo poo Pauls work I think it's an amazing idea and I'd certainly like to see what it can do, just wish I could plug the ULAplus in a machine right now!!

    You can. It's just non-trivial. You get the open core featuring ULAplus support and you put it on a CPLD with external RAM or an FPGA and you plug it in in place of the ULA.
  • edited August 2012
    Glad you like it, ULAplus was what kicked the whole idea off tbh, it's the only way to get something that would closely resemble old arcade top down racers.

    Well at the moment it's a case of recouloring the tiles, but some of the tiles have been redesigned to allow better use of colour and shading (the little ball shaped tree thing I have done (in the piccy wrong shading perspective on that) to use more shades of green to give better shadowing etc) so I think I'll be using all 4 CLUTS to acheive what I 'hope' I can pull off!

    I'll have to give the FPGA a look, I'd like to plug it into real hardware.
  • edited August 2012
    BiNMaN wrote: »
    I don't want to poo poo Pauls work I think it's an amazing idea and I'd certainly like to see what it can do, just wish I could plug the ULAplus in a machine right now!!

    I'm sure there are currently more than one approach to produce ULAPlus in physical form. This is mine:

    ulaplus_board_rev1.png
    (if you print this picture to real size (it's a 300dpp PNG image) you will have an idea of how much space this board will take in the Spectrum PCB)

    It's designed to (hopefully) fit in the place of the ULA in 16K/48K/plus Spectrum boards.

    I'm waiting for some time (and money) to build a prototype board, which will be bigger than the "production board" shown here, and test if my -somewhat cheap and dirty- solution to make the FPGA tolerant to 5V inputs really work as Xilinx advertises (I'm afraid that the data bus lines of this ULA might not have enough strength to be read by the Z80)

    The soft-core inside this ULA is based in the same core I've published at OpenCores. That is: accurate timmings as per Chris data, Timex HiColour mode, and ULAPlus. I've not implemented Timex HiRes (yet) but this can be easily added to the core.

    The design uses two main chips: a Spartan 3E FPGA with 100K gates, and a Platform ROM to store the bitstream. A 50MHz oscillator feeds the DCM (Digital Clock Management) inside the FPGA, which in turn generates all the signal clocks I need (currently only one: 28MHz, which is divided by two to obtain 14MHz).

    This ULAPlus implementation outputs analog RGB and optionally, PAL composite video with an AD722. By using a sigma-delta coder, /Y,U and V signals could be generated as well, for a true plug-and-play solution. The soft-core published at OpenCores uses sigma-delta modulators to produce an analog RGB signal (using a 56MHz S-D clock). Here the RGB signal generation is performed by means of weighted resistors.

    I could have chosen a Spartan 3AN, which has the platform ROM embedded, but the 3A family has an issue: it lacks the clamp diodes in their pins (to allow for faster signals). These diodes don't allow dangerous voltages to enter the logic cells, redirecting them to Vccio or GND. According to Xilinx's, these clamps allow the device to be made 5V tolerant by putting 270 ohm resistor in series with the pins that are going to be used as inputs, limiting the current flow through the clamp diodes to a safe value.

    Some GPIO's (visible at the right edge) have been made available to further enhance the capabilites of this "ULA". For example, an AY-3-8912 can be implemented inside it, to give 128K AY-style sound to 48K machines (although this implementation would have to contend AY ports, which are not actually contended).

    There is even enough space to implement a small coprocessor, or DMA engine, to assist the CPU in block moving, or sprite rendering.
  • edited August 2012
    I could have chosen a Spartan 3AN, which has the platform ROM embedded, but the 3A family has an issue: it lacks the clamp diodes in their pins (to allow for faster signals).

    You can always have external clamp diodes, but that would probably end up taking up more space (and costing just as much) as the platform ROM so, well, on second thoughts sticking with the non-A version might be better :-)
  • edited August 2012
    - It main purpose is not to offer a wide range of colours. That, I think, it's a "side effect". Its main purpose is to mimic screen contents to output them in RGB mode to improve picture quality. This is something that Winston talked about some time ago, but his idea was to use a line-size double buffer to output the picture to a VGA monitor.

    For just improving the picture quality, it wouldn't matter if it was for a rubber/plus 48K machine only given all the 128K models already can do RGB out and have very nice picture quality - perhaps that's his line of thinking.

    I did some playing around when thinking about a VGA card for the Speccy in terms of how to keep the thing synchronized without relying on the video signals that are only present on the 48K for sync. Just to stop anyone else going down the same rabbit hole, I hit upon the idea that I might be able to use a phase locked loop and stable enough oscillator to regenerate the Spectrum's clock signal (and therefore keep the board's clock signal going during periods of contention - the ULA basically suspends the CPU clock during contention, but my oscillator would keep on running). However, the frequency always drifted a bit too far if there was a lot of contention going on and not enough clock cycles then things tended to go a bit pear-shaped after that, and I could never make the VCO good enough not to drift too far if you wrote a short program to make the worst case contention.

    Of course you could use the video sync from the composite video and still have it work on non-48K machines - for 128K machines, simply have the user connect the composite output to the VGA card via a short lead and obtain the sync from that, it just wouldn't be quite as neat as it would be on the 48K.
  • edited August 2012
    Although I see the maybe missed opportunity of implemention of ULA Plus, I think all people focus on the new graphic mode, but not that it is simply also good to have an opportunity to connect the old Spectrum to modern TV. I see even a big demand for an interface doing just this, be it with new graphic mode or without.

    I would like to see this for Spectrum 128k as well, as the Spectrum 128 has an RGB - output, but as the PIN 16 signal is missing, most TV?s do not recognize it as a RGB-signal and just use the composite signal. I know, anybody can fix this missing signal, but most users out there don?t want open the Spectrum and solder at the RGB port. So such an interface would be a great thing.

    I think it is not available to buy yet?
  • fogfog
    edited August 2012
    aowen wrote: »
    I already contacted him. Haven't heard back yet.

    he's a busy chap,with other stuff also (zx81 etc) sure you'll hear back from him , just give it a bit of time.
    If you bought stuff off him , he made it known in an email must be 2 months ago now , with regard to this item. I was impressed, but the only nit picking I did was no 2 joystick ports.

    I use a few of his interface 2 carts :) (the diagnostic one comes in very handy)
  • edited August 2012
    Some GPIO's (visible at the right edge) have been made available to further enhance the capabilites of this "ULA". For example, an AY-3-8912 can be implemented inside it, to give 128K AY-style sound to 48K machines (although this implementation would have to contend AY ports, which are not actually contended).

    They are on the original 128, the UK model and the Mk I grey +2. All I/O is contended on those machines owing to a bug in the HAL chip.
  • edited August 2012
    fog wrote: »
    he's a busy chap

    Oh I wasn't expecting a reply any time soon, just wanted to let the OP know that I had sent a message. Paul and I have been talking speccy projects for a long time now. I bought one of his IF2 carts to run SE BASIC on a machine without modifying it, but that's gone along with the rest of my speccy hardware now. I'm waiting for a Spectrum SE compatible machine because frankly once you've used 80x24 mode, you really don't want to go back to making do without it.
  • edited August 2012
    I'm sure there are currently more than one approach to produce ULAPlus in physical form. This is mine:

    ulaplus_board_rev1.png
    (if you print this picture to real size (it's a 300dpp PNG image) you will have an idea of how much space this board will take in the Spectrum PCB)

    It's designed to (hopefully) fit in the place of the ULA in 16K/48K/plus Spectrum boards.

    I'm waiting for some time (and money) to build a prototype board, which will be bigger than the "production board" shown here, and test if my -somewhat cheap and dirty- solution to make the FPGA tolerant to 5V inputs really work as Xilinx advertises (I'm afraid that the data bus lines of this ULA might not have enough strength to be read by the Z80)

    The soft-core inside this ULA is based in the same core I've published at OpenCores. That is: accurate timmings as per Chris data, Timex HiColour mode, and ULAPlus. I've not implemented Timex HiRes (yet) but this can be easily added to the core.

    The design uses two main chips: a Spartan 3E FPGA with 100K gates, and a Platform ROM to store the bitstream. A 50MHz oscillator feeds the DCM (Digital Clock Management) inside the FPGA, which in turn generates all the signal clocks I need (currently only one: 28MHz, which is divided by two to obtain 14MHz).

    This ULAPlus implementation outputs analog RGB and optionally, PAL composite video with an AD722. By using a sigma-delta coder, /Y,U and V signals could be generated as well, for a true plug-and-play solution. The soft-core published at OpenCores uses sigma-delta modulators to produce an analog RGB signal (using a 56MHz S-D clock). Here the RGB signal generation is performed by means of weighted resistors.

    I could have chosen a Spartan 3AN, which has the platform ROM embedded, but the 3A family has an issue: it lacks the clamp diodes in their pins (to allow for faster signals). These diodes don't allow dangerous voltages to enter the logic cells, redirecting them to Vccio or GND. According to Xilinx's, these clamps allow the device to be made 5V tolerant by putting 270 ohm resistor in series with the pins that are going to be used as inputs, limiting the current flow through the clamp diodes to a safe value.

    Some GPIO's (visible at the right edge) have been made available to further enhance the capabilites of this "ULA". For example, an AY-3-8912 can be implemented inside it, to give 128K AY-style sound to 48K machines (although this implementation would have to contend AY ports, which are not actually contended).

    There is even enough space to implement a small coprocessor, or DMA engine, to assist the CPU in block moving, or sprite rendering.

    How much would this cost to prototype?? I might be interested, send me a PM.
  • edited August 2012
    I might be interested, send me a PM.

    me too...
  • edited August 2012
    It's more a matter of time than money. Parts (most of them) are already bought, at least to build 5 ULA's. I have to re-check the design before holding my breath and send it to the PCB house (that's not much money, about 35-40$ for 10 pieces).

    The hard part comes next: properly align the VQ100 FPGA chip, solder it, and hand soldering those tiny 0603 resistors one by one with twezzers fine enough for 1206 and 0805 parts, but a little sturdy for 0603 parts. Thought about ordering a stencil and use solder paste, but I haven't got any previous experience with that. Is it really helpfull? Do I need an owen for this? (not thinking about baking Andrew :P )

    My main fear with this design is that the method I've used to make the FPGA 5V tolerant (placing 270 ohm resistors) is not by any means the best and the most recommended, but it's way cheaper than some level shifter buffers, and it's mentioned by Xilinx in their app notes. Besides, it's the method used by Digilent in their FPGA trainers to interface FPGA with PS/2 keyboards and things like that, so... it should work :O . Once I have one ULA working, I want to leave the Spectrum with it running at least 24 hours to ensure that the FPGA input buffers have not suffered any damage.

    On the other hand, I'm wondering how much would cost to let a fabric do the PCB's and solder the components (at least, the SMD ones). Paul Farrow's device seems to be made professionally. PQ208 FPGAs like the one he has used, are a real pain to hand solder (I speak from first hand)
  • edited August 2012
    Arda wrote: »
    me too...

    Me three...

    On a side note (and forgive me for not reading up) I see that specemu and spin allow ULAplus on a 128, I was under the impression it was 48 only - is it possible for a real 128 machine? Would it have to be an external mod rather than a plug in (especially on a +2a/b/3)?
  • edited August 2012
    BiNMaN wrote: »
    Me three...

    On a side note (and forgive me for not reading up) I see that specemu and spin allow ULAplus on a 128, I was under the impression it was 48 only - is it possible for a real 128 machine? Would it have to be an external mod rather than a plug in (especially on a +2a/b/3)?

    Of course it's possible in a 128K machine. In fact, my first thought was to develop a 128K version first (would have more space for the PCB, no need for an oscillator...) but it turns out that I have many more spare 48K PCB's for testing than 128K boards. Besides, it seems that the 48K have a less robust ULA than the 128K (the +2 grey adds a small heatsink, contributing to span its life a bit more) so there's likely to be more 48K damaged ULA's and hence, more people interested in a replacement :)

    The +2A/+3 is a different beast... Much more space for a PCB for an internal mod (which is definetly doable), but it won't be a plug-n-play solution of course. A external plug board, such as Paul's is the solution, but it would be very helpfull to have the master clock (35MHz) available at the rear bus so using that clock and the 50Hz INT signal would be enought to keep the external ULA in sync with the internal one (well... I guess Winston's solution about using the CPU CLK and using a PLL to synthetize the master clock would work here, as the CPU clock is not interrupted)
  • edited August 2012
    well if anyone does decide to make a batch I would be interested in a grey +2 version, it's one that I'm adding bits and bobs to, it already has velesofts replacement HAL to match the +2a/b/3 memory contention and hopefully spectrum se rom set over the weekend
Sign In or Register to comment.