The benefits of prototyping, even the smallest of designs.

 

As the existing stock has being cleared, it needs to be replenished, progress has been made to do this. The Retro ATX adaptors (not Amiga specific now), have been prototyped and the first two prototypes assembled as shown here

New_ATX_2015-medium

On the left is the small form factor design, primarily aimed at the picoPSU ATX power supply. On the right is the multi-purpose ATX adaptor (formerly Big Box), aimed at higher power systems and those that require additional features, notably -5V supply, 50/60Hz mains tick and AC fail status.

Some of my regular customers will notice a move away from the Amiga specific titles. The reason is simple, these adaptors will work with multiple retro systems, a name change can help generate more sales and of course happy customers. This has in part been driven by feedback from customers, asking if these adaptors work with other systems, the answer is yes. If you have a vintage retro system, with a 1980’s power supply, you may be at higher risk of power supply failure due to aging effects due to heat and dried up electrolytic capacitors. Replacing your old power supply can provide some peace of mind.

I will provide details on wiring up these adaptors for various Retro systems, including the BBC Micro, Apple II and Sam Coupe among others on my website in due course. It is not viable for me to supply power adaptors for systems that require a 9V DC supply, like the Oric Atmos or Sinclair Spectrum, as you can easily purchase modern switchmode converters.

For low power systems, I recommend a genuine picoPSU adaptor, manufactured by Mini box. Unlike most high power ATX adaptors, these converters have no minimum load requirement and are silent. A typical 230W+ power supply will have a minimum load rating, to ensure the outputs are stable so to use a regular 230W+ power supply with a retro system, using 25W, you need load resistors, sometimes dissipating upto 25W of power!

The prototype PCBs were ordered from a local company, Ragworm, hence the orange silk screen. The build quality was very good and it took me just over an hour to assemble the boards. As the aim was to get these PCBs assembled by a contract manufacturer, the existing designs needed a few refinements. All components are now on one side of the PCB, this reduces the number of process to 2 (SMT load top side and hand solder) from 3 (+SMT bottom side). This saves on the recurring costs. The control electronics have been simplified, reducing the part count. All control is now via a Microchip PIC10F202 micro-controller in a tiny 6 pin SOT023 package (3mm x 3mm), programmed on card via an ICD 3 programmer. This allowed for easy configuration for momentary or latched power switches and improved de-bounce compared to the previous design. It also provides a 50/60Hz square wave output, useful for some Amiga models that require a mains ‘tick’ signal. Finally the design also switches on/off the supply.

On both boards, I have added extra, larger, pads for connecting your own power wiring in addition to a 2 pin header. On the multi-purpose adaptor, the number of +5V and 0V connections have increased from 2 to 4, making it easier to connect to a high power, 100W+, system (mainly Amiga 2000/3000/4000). Simple changes that were easy to implement.

What did I learn from these prototypes?

For the Multi-purpose adaptor, the text describing each power rail, by the screw terminals, should be rotated 180 degrees, making it easier to read when wiring up. The linear -5V regulator needs more copper area to act as a heatsink.

Order your programming cables long in advance! To program the PIC micro and save on recurring costs, I decided to use a Tag Connect, TC2030-MCP-NL programming cable, this only requires a tiny PCB land pattern on the PCB. It may not seem much, adding a 20p, 1.25mm connector to each PCB but on a batch of 200 PCBs, it certainly adds up. The annoying part is getting hold of the cables. I currently have a cable on back order from Farnell, expected delivery date is 10th August! Finding stock in the UK has been tricky.

The other prototype PCB has been the V2.5 Amiga floppy adaptor shown here:

New_Floppy_2015-medium

This board showed the benefits of prototyping. You may notice the orientation of the drive connector is odd?
I designed this board to have a reduced form-factor to easily fit behind the floppy drive, adjacent to the drive, this did not work. The problem was that some drives, like the Mitsumi drives in my collection, have the +5V power connector above the 34 way IDC connector. So with the PCB plugged in, you can not connect the power, oops.

This new PCB is 60x24mm, the previous (V2.1) PCB was 53x40mm. The ideas was to make it smaller to fit more easily inside the Amiga and to allow easy assembly into a case to act as an external DF1 floppy drive, either with a real floppy drive or with a HxC or USB (Gotek) virtual drive. Moving the design to Little Logic and 0603 surface mount components allowed me to make the PCB much smaller.

As well as the mechanical error with the power connector, it also highlighted a limitation of the Design Rule Checks (DRC) that I run on the PCB data. One of the floppy drive connectors (the white one in the photo) is too close to a couple of resistors, this could easily be damaged in assembly and would limit inspection and rework.

The production PCB will be 5-7mm longer and the same width as the IDC box header, the two jumpers, one on either side will move into the extra space.

I am learning how to use mechanical 3D design tools (Sketchup and 123D), as an electronic engineer, they have taken some learning. I do want to master one or both tools as a 3D printer is on my wishlist. Sometimes you can’t beat a real prototype though.

The PCBs shown above need further testing before I release them for manufacture in batches of 100 of each design. The lessons learnt, minor in some cases, from these prototypes has been invaluable. Once the design release is complete I can get back to my other projects in earnest. Until the next post.

Ian

Advertisements

GBS-82XX experiments part 2

GBS-8200 and GBS-8220 experiments part 2

Work has continued, experimenting with these low cost but potentially highly capable video adaptor boards.

Fixing the random speckles on the display

I believe I have found the cause of the occasional white speckles seen on the display. The default setting for the GBS-82XX board is to clock the 166 MHZ speed grade SDRAM at 162 MHz. It appears to be worse if the Hynix HY57V643220DT-6 is fitted compared to the EtronTech EM638325TS-6G device, which appears to be fine.

I measured the SDRAM clock at 162 MHz and recorded this:

gbs-clock-small

Whilst the signal is a bit noisy, it does not violate the +/-2V overshoot/undershoot limits of the SDRAM devices used.

The simplest fix was to reduce the SDRAM clock speed to 129.6 MHz, with a single I2C write. This has fixed the issue. Halving the SDRAM speed to 81 MHz caused distortion on the video, the next speed increment of 108 MHz was sufficient for 1360×768 pixel output. A proper fix would be to adjust the timing of the DQM strobes with regard to the data bus as on SDRAM the DQM strobes clock the data out of the SDRAM. If this is adjusted, you also need to consider the timing of the SDRAM clock to the control bus (RAS, CAS, CKE, CS, BS0/1 and WE) and the Data bus. This is not too difficult if you have the PCB artworks as you can measure the PCB track lengths and adjust the timing by 7ps/mm. With the GBS-82XX board, it would be tricky and fraught with false starts. We could of course measure it and adjust accordingly, or reduce the clock speed by 20% and have more timing margin (an extra nanosecond) on the clock.

Now that the speckling problem appears to be fixed, I am looking at some general video quality issues. When using a 50 Hz PAL screen-mode, scan-converted to 60 Hz, there are some noise bands, particularly noticeable on a grey Workbench background. It is hoped that some digital filtering/sampling will help alleviate this.

Synchronising the GBS-82XX

I have experimented with different ways to synchronise the GBS-82XX device. As those of you that have experimented with the board now, sometimes it can be a bit ‘hit and miss’ with the video source (games console or computer).

When using the GBS-82XX with the Amiga, this is the cable I use:
GBS-82XX-cable

The 680 ohm resistor is essential. It reduces the CMOS Composite sync signal from the Amiga to < 3.6V. The TVIA-5725, the device under the big heatsink, accepts a maximum voltage of +3.6V and a minimum voltage of -0.3V. The Amiga’s video sync, measured on the A1200, looks like this:Amiga_CSYNC_680R_GBS8220
The TVIA-5725 accepts a 3.3V TTL signal, via a Schmitt input, this changes logic levels slightly so a logic 1 is 2.4V to 3.3V,  and a logic 0 is 0 to 1.0V. The 680 Ohm resistor works as the GBS-82XX follows the Vesa VSIS specification, which requires synchronisation inputs to have a 2K impedance to ground. My 680 ohm resistor (+47 ohms in the Amiga), creates a potential divider, reducing the signal level to a safer level. This is cheap and easy to implement and does not degrade the video sync significantly.

A number of people use the venerable LM1881 video sync separator, any device or circuit that uses this, should have the 680 ohm resistor added as shown above. The LM1881 outputs 4-5V sync levels that are not compatible with the GBS-82XX/TVIA-5725. Alternative devices are the EL1883 or the LMH1980 but they are not available in hobbyist friendly DIP packaging.

I have tested the LMH1980 with the Amiga, I used the composite video output of the A1200 to create LVTTL (3.3V) HSYNC, VSYNC and CSYNC. The GBS-8200 I have synchronised with the CSYNC perfectly, the same as using a resistor. It did not work reliably when I supplied separate HSYNC and VSYNC, I had a very wavy display.

A final note, the GBS-8200 did synchronise to the Composite video output of the A1200 but it is not recommended. The 2V (approx) video contains colour information that is not filtered out and would in all eventualities, cause problems at a later date.

Cleaning up the power supplies

I have been reading numerous web-forums on GBS-8200/GBS-8220 problems to look for common trends and solutions. One topic that crops up a lot is related to the power supplies. I have already proven, in part one, that a 5V 2A supply is not required.

During my testing, I noticed an occasional, high frequency, burst of noise, on the +3.3V supply. I traced it back through the circuit to the power input. Changing the timebase of the oscilloscope, I spotted something important, it happened at 20ms/50Hz intervals. In the UK and Europe, the AC mains operates at 50Hz so when you see a 50Hz noise pulse, you know where it came from. Currently my GBS-8200 is powered from my bench power supply, built 20 years ago, with 3 linear regulators and still on the original electrolytic capacitors.

Also connected to the +5V output was my 5V to 3.3V TTL buffer board. Two of the eight inputs were in use, the other six were floating. I made a mistake here. You should never leave TTL inputs unconnected, they will pick up noise and oscillate, in this instance, they picked up 50Hz mains noise. Quickly dis-connecting the buffer board, removed the noise. The 3.3V (switchmode) and 1.8V (linear) regulator supplies now have about 20-30mV of noise, perfectly acceptable.

To ensure I do not have any further conducted noise issues I added a clip on ferrite bead:
GBS_with_ferrite

You can see the buffer board in the top right of the photo. Whilst this ferrite was a little large, it did cut the noise out. If you are using the DC power jack (the black plug) either pick a PSU that has a ferrite fitted or measure the cable diameter and purchase a clip-on ferrite from a local supplier or ebay. I spent two hours trying to work out where the noise was coming from, reading datasheets and measuring the board.

To date I have changed a single capacitor on the board. I briefly touched on this in my first post but after additional testing, I am happy to confirm it needs changing.
Here it is:
Capacitor_to_change-medium

The 1.8V regulator is used for the core supply of the TVIA-5725. with a ceramic capacitor, I was able to cause the power supply to glitch by switching my overhead inepection light on/off or my soldering iron transformer. Since changing it to a 16V, 22uF, tantalum bead capacitor, this has not happened. The original capacitor, shown under Kapton tape, had an ESR of 0.02 ohm, the recommended range for the LM1117 (similar to the AMS1117 used here) is 0.3 to 22 ohms! The part I fitted had an ESR of around 2 ohms.

The software settings solution?

Some people ask what the final software settings solution will be?

My preferred option is to use an Arduino Nano like this:

ArduinoNanoFront_3_lg

(Image from http://arduino.cc/en/Main/arduinoBoardNano)

This would be used to read and write the I2C commands to the TVIA-5725 device which provides the video scaling functions, among others. It is readily available and clones can be cheaply procured, finally it can be easily updated using the Arduino environment.

My aim is to make the design data readily available, for free. This will include the video settings. I’ve seen too many scammers on ebay selling ‘Amiga modified’ equipment for extortionate prices, I will not have this solution exploited.

Another option, still using the Arduino approach is a module that piggybacks on the 8051 microcontroller clone on the GBS board. This would allow access to the onboard switches and no wiring. The downside is it would be more expensive.

Until the final settings are known, the end solution is fluid.

Until the next update.

Slow and stedy

It’s been a while since my last post  and as one of the aims was to use a blog to provide more updates, I need to get busy.

Block diagrams are excellent

The design is still progressing, it’s just taking a bit of time. One of the first important steps for me is to sketch a block diagram of the system, here is one I made earlier:

Hermes_CD32_block

It might not look the most exciting diagram but it helped to plan the design. From this it was easy to get a feel for the number of I/O pins for the CPLDs, it showed me where I need the 5V/3.3V logic translation and what discretes were needed.

The design has three discretes/jumpers. The first is an enable/disable jumper (or switch). If A game refuses to work with the extra RAM, you can easily disable the whole card. PATA should not be affected but is to be confirmed.

There are  another two discretes are related to the floppy drive interface. The first input tells the CPLD if either a PC(default) or Amiga floppy drive is connected. This is so I can crossover the important signals (CHNG/RDY) and generate the RDY signal. The other discrete input/jumper is if a duall floppy drive cable is used with a twist, it will again allow me to crossover signals. The floppy interface by default supports PC floppy drives as they are cheaper to obtain.

The final option is a 4MB/8MB RAM selector. To cut costs, this would allow a system with 4MB of RAM. May not be used.

From this diagram I sketched out (but have not shown here) the top level blocks of the Memory and Interface Adaptor (MIA) CPLD. This helps me plan a logical flow for the CPLD. Without this I would not have thought of some of the extra switch inputs.

Changing CAD software

This might seem crazy and it has delayed me a little bit but I took the decision to change the CAD software I use. Since 2002 I have used Cadsoft EagleCAD, a fine tool I know well. I currently use V5.11, which is stable and does most of what I need. One of the limitations is PCB area. Up until now, a 160x100mm PCB area has been sufficient. This design might be greater than that.

I currently have a standard license, which costs 690 Euros+VAT. To move to the Professional edition, for a larger PCB area, the license is 1385 Euro+VAT!  As a registered user, my upgrade costs are slightly reduced. The software upgrade costs would out-strip any money I make from this project, so a cheaper solution was required, enter DesignSpark PCB.

Designspark has had a learning curve, sometime steep but it was not unexpected. I have had to create a few schematic and layout symbols but that is inevitable and a good chance to learn. The online help is Ok but a bit lacking in some areas (took a while to find how to easily edit existing library symbols and download many of them). No schematic tool is perfect though. In addition to Eagle CAD I also use Mentor Graphics schematic tools in my day job, sometimes I try shortcuts from one tool in another.

One area I do plan to use Designspark PCB for is the 3D modelling and mechanical design. It easily creates a 3D view of the PCB, from within the package. With Eagle I have to run a script, export to Sketchup and render, not as easy as one click. In the future, I will put the Designspark Mechanical training to use and export my PCB into a 3D model.  Ok I need to create a basic model of say a CD32 enclosure and a clockport card but it will help. No pain no gain.

I have some ideas of how to make a product tester, this has helped with the design a little as it made me added a few test signals to the edge connector and also how to easily verify a batch of boards.

 

Progress to date

This will be asked so I might as well say how it is going.

The basic schematics I had have been re-drawn in Designspark. It was mainly some TTL logic, RAM and a CPLD.

The bulk of the remaining schematic work depends on the MIA CPLD design. This will drive the device pinout, taking into account PCB routing. Future efforts will focus on this device. My CPLD design skills are Ok, they need to improve, one of the aims of this project.

I will not have a prototype PCB by the end of June 2014 as I planned. A finished schematic diagram would be good and a mostly finished CPLD is my aim by the end of June.

There is still some static timing analysis to be done, around the CPU and SRAM interfaces but I need to finish some of this to constrain the CPLD timing.

The plan after it has been tracked is for 2-4 prototypes, they will get comprehensively tested and from there, depending on interest, look at production.

I hope to have another update early July.

 

Ian

Component selection

Component selection decisions for project Hermes

I thought I would share some of the decisions made whilst selecting the components for the design and how they impact the overall design, in terms of cost, complexity and testability.

The first big decision is the number and types of CPLD/FPGA devices for the interface logic. The original plan was to use a Xilinx XC9500XL series CPLD. Whilst they are not the most exciting of devices they have a few key benefits:

  • Low cost, around the £5 to £10 unit price in small quantities.
  • Available in density from 36 to 288 Macrocells.
  • 5V tolerant, this reduce the amount of external logic.
  • Available in solderable (for prototype) PQFP SMT packages
  • Work with the free vendor design tools.

Xilinx was selected as my preferred logic vendor as I have previous experience with the devices at both a PCB implementation and at HDL level.

The majority of the design uses 3.3V logic, if the chosen CPLD can be 5V tolerant, it reduces the need for 5V to 3.3V level translation on some input only signals, like the address bus and the control bus. This is not a key feature. The number of macrocells and I/O count was surprisingly more important. The basic IDE interface required 71 I/O pins and 81 macrocells and 137 functional blocks. Factor in the extra I/O for a floppy interface and the address decode for the RAM and you have over 100 I/O pins.

An important selection criteria, for any CPLD (Xilinx, Altera or Lattice) was availability in a PQFP package as I want to avoid the BGA options. These devices tend to be limited to a 208 pin PQFP package, in up to 144 macrocells for Xilinx. Whilst the device may have 208 pins, it may only have  around 100 I/O pins. The safest way to implement all the required logic is to split it across two devices as I do not want to use more than 70% of the resources (excluding pin count) of a device, to give some room for changes/routing. The IDE design is borrowed from the IDE68K project which fills a 72 macrocell CPLD. The existing CPLD design could be re-used as-is and the PCB tracked to suit?
To be decided.

Adding the SRAM memory interface and  autoconfig logic (borrowed from the A608 DRAM controller which takes 22 macrocells, and 32 pins) , into another low cost CPLD seems to be a sensible split. This would be logical to add the clockport interface to.

The beauty of hardware description languages is the ability to ‘fit them’ to target devices and view their resource usage, before purchasing any components. You can also run gate level simulations but that is for another day 😉

It has been glossed over but the memory interface uses SRAM not DRAM. Component availability and simplicity of design were the key points. It is possible to procure new SRAM devices, either the Alliance, AS6C1616-55TIN, a 55ns 16 Mbit (2Mbyte) or the R1LV1616RSA-5SI#B0 could be used. They share a common 48 pin TSOP package, allowing the lowest cost part to be used. A 55ns speed grade is fine when connected to the 14 MHz (69ns) system clock of the CD32’s 68EC020 microprocessor as it takes 3 clock cycles (about 220ns) to do anything. Once the timing diagrams are finished I will publish them here.

A DRAM controller and SIMM socket would be £20-30 cheaper to implement but the lack of new SIMM sticks and the potential headache of supporting multiple , old, and potentially bad, SIMM modules, makes a common SRAM solution easier to support.

The PCB will be a 4 layer board.  The cost differential was £4 per board moving from 2 layer to 4 layer but it makes the tracking so much easier as the inner two layers can be power planes with limited tracking if required. This also facilitates a controlled impedance board, important if ‘245 type buffers are used to translate 5V to 3.3V, as they have 10-20 ohm output drivers, which with appropriate series resistors, will facilitate fixing the signal integrity issues that will occur.

Once the above have been taken into account, the detailed design can begin.

Introducing project Hermes (RIP)

Update August 2017, project now on indefinite hold
Project Hermes was the codename for an expansion card for the venerable, Amiga CD32 games console, spurned from discussions on the EAB web-forum http://eab.abime.net/showthread.php?t=72361.

The aim is for this blog to be used to track developments and get feedback from fellow users. This wordpress site will also be used to try out the format and will detail non-amiga projects too. My main website, http://www.ianstedman.co.uk, is still active.

The design aim is to produce a couple of prototype expansion boards that allow the CD32 to function as a a fully fledged computer, akin to the Paravision SX-1 or DCE SX32/Pro expansions from the 1990’s.  The idea is to provide an affordable, modern alternative to these units. The author owns a DCE SX-32 Pro unit, which with hard drive cost £600 back in 1997! A new expansion board will cost considerably less than this.

Specification

8 MB SRAM
Parallel ATA (IDE)  port + Compact flash connector.
Floppy port, capable of accepting Amiga or PC floppy drives and floppy emulators.
Real time clock?
Clockport connector to allow for I/O expansions.
Enable/disable logic + switch, for those old games.

Expected cost, around £120.

The question will inevitably be asked, why no accelerator?
KIS (Keep it Simple).

A CPU upgrade will add extra cost and break compatibility with some games, the CD32 after all is a games console. Yes some games would benefit from a faster CPU but the FPGA accelerator technologies, freely available, in the author’s opinion are not ready for use without adding significant risk to the project.

Why is SRAM used not a SIMM socket?

Stability. Even a slow 70ns SRAM, will operate with zero wait states on a 14 MHz MC68EC020 (71ns)bus that takes 3 clock cycles to do anything. Whilst a SIMM slot would be much cheaper to add than SRAM, £1 compared to around £20 for 8 MB of SRAM, age of devices and support are primary concerns. SIMMS are obsolete technology, you can easily buy them from ebay and some old computer shops. Their reliability and speed grades are unknown. Size and speed detection can be troublesome. By supplying a ready-built system with RAM, you do not have the worry about finding suitable parts, this reduces the support costs.

What’s next?

Future posts will provide a few diagrams of the unit and progress to date. The FPGA/CPLD logic is in development, more on this in a future posting. It is anticipated that the first PCBs will be designed May 2014, building of prototypes will commence around this date. Yeah kind of missed that deadline

Crowd-funding is being considered for this project.

Ian