Saturn Cartridges - Gallery

Saturn Cartridges - Gallery

Many pictures of the homebrew Saturn cartridges I designed and populated so far
I started electronics when USB dev cart project was announced on Segaxtreme forums somewhere in Summer 2012.
First, I just populated USB dev cart, then started to design my own cartridges, with the goal to make a Saturn memory cartridge using SD card.
Since I was a complete beginner about PCB design and SMD soldering, I made many broken prototypes until getting something working, and thought it would be funny to gather all theses prototypes on this page

USB dev cart and Gamer's Cartridge Gallery

Wasca Gallery

USB dev cart - Rev 3 PCB Design : June 2012

This is the initial PCB revision of USB dev cart by antime.
It supports only 256KB flash ROM (128KB x 2 chips), but this is OK for installing USB dev cart original firmware or Pseudo Saturn Kai.
I'm nostalgic about this PCB revision, because I learnt SMT soldering with it

"Rev 3" cartridge. Very first one I made (?)	"Rev 3" cartridge. (Condensers, resistors unpopulated)
"Rev 3" cartridge.	Another "Rev 3" cartridge.

Many "Rev 3" cartridges

"Rev 3" cartridge, rear side in official Memory Cartridge shell.

Saturn Cartridge - Rev 1a PCB Design : Sept. 2012

First time I designed a PCB ... the result was horrible
The only success in this prototype was to allow 1MB flash ROM (= 512KB x 2 chips). Except that, everything was wrong : no power regulator to feed SD card, mistakes in glue logic, etc.
My best lesson from this proto was : "don't trust the PCB auto-router, unless you know how it works" : I initially thought auto-router was a great tool to do the dirty routing job instead of humans ... it wasn't as expected, hence the result looks like a mixed spaghetti meal
I don't say that auto-router is bad : it is for experienced users ! Beginners shouldn't use auto-router, but rather do PCB routing by themselves in order to understand how PCB routing works.
(And in Saturn cartridge case, routing everything "by hand" is actually funny )
Well, this was an occasion to get used to KiCad and SMD soldering ... I actually wasn't expecting anything from this prototype

"Rev 1a" cartridge. (You probably guessed it doesn't works )

Saturn Cartridge - Rev 1b PCB Design : Oct. 2012

Rev 1a was USB-less ... and consequently, debugging programs with it was a nightmare , so USB module was restored from Rev3.
Few things regarding glue logic were fixed, and I started do manually route the PCB.
Also, a spare SD card socket (standard size, not micro SD size) was added, and because of its dimensions, SD card sockets were moved to PCB rear side.
Basically, it was an USB dev cart with 3 LED turning on or off when writing a register on the cartridge (), but with some rework, and external power supply for the SD card, SD card SPI access was sometimes possible

"Rev 1b" cartridge used as USB dev cart. (ICs related to SD card are left unpopulated)

Fully populated "Rev 1b" cartridge (Tape is used to protect ICs when unplugging PCB from Saturn).

"Rev 1b" cartridge, showing SD card register. First time I could access SD card via Saturn cartridge

Saturn Cartridge - Rev 1c PCB Design : Dec. 2012

Next attempt to interface SD card by adding a 3.3V step-down power regulator from sd2snes project. With stupid details (forgot pull up resistor on SD card's DOUT line, etc) fixed, this probably would had interfaced SD card without major problems.
Also, as I became used to KiCad, I added a 128KB SRAM chip on PCB rear side ... finally removed on Gamer's Cartridge since it wasn't required to get it working.
(Glue logic for this SRAM chip was buggy in this version, making incorrect 8 bit data write on SRAM.)
Cartridges were manufactured with gold plating on pads, in order to see if it was better than normal plating ... nothing really special to notice, so I revert to normal plating on next prototypes.

"Rev 1c" cartridge used as USB dev cart. (ICs related to SD card are left unpopulated)	Another "Rev 1c" cartridge, used as USB dev cart.
Fully populated "Rev 1c" cartridge, put in official Memory Cartridge shell. This was my main dev cart for around half a year until I sell it	Fully populated "Rev 1c" cartridge, rear side with SRAM chip and SD card socket.

Saturn Cartridge - Rev 2a PCB Design : July 2013

First PCB revision using CPLD I used Altera's EPM3128 (TQFP package, 100 pins), resulting in terrible results due to my poor experience in soldering these relatively fine pitched (0.5 mm) ICs ...
But thanks to the usage of CPLD, SRAM access could be easily fixed in 8 bits write mode
It worked for a couple of months, then stopped to function correctly ... I suppose this was due to CPLD soldering ? (At that time, I was still soldering ICs without using flux, which probably damaged the CPLD)
There wasn't any plan to put it in a cartridge shell, so I designed this PCB at 100mm x 100mm dimensions, because PCB manufacturing costs are same as standard size (100mm x 70 mm), resulting in a "fat" cartridge design.

"Rev 2a" cartridge, a couple of months before manufacturing it.

"Rev 2a" cartridge, ready for testing.

The same cartridge, few months after. (As you can notice, I forgot to route some signals on the cartridge connector ...)

Saturn Cartridge - Rev 2c PCB Design : Jan. 2014

Attempt to add DRAM, as used in Action Replay cartridges. Because I wanted this PCB revision to fit in a standard cartridge shell, I routed flash ROM and DRAM in a relatively weird way (half of the ICs on front side, remaining half on the rear side), but making everything routable
Also, I put "extra" stuff (USB connectivity and SD card socket) available from separate board ... with wires (not connector) interface between theses two boards, giving in a "spaghetti" result to the whole
There were many new things I tried, many others I wanted to challenge with this board, and ... everything was a complete failure. I don't want to hear about this board anymore.

"Rev 2c" cartridge, (WIP). Just finished to route Flash ROM and DRAM stuff.	"Rev 2c" cartridge preview, just before sending to PCB manufacturer.
"Rev 2c" cartridge, ready for testing.	Extra dev board with USB and SD card socket.

USB dev cart - Rev 2e PCB Design : Aug. 2014

First PCB revision on which I separated USB dev cart and Gamer's Cartridge projects
This PCB focuses on USB dev cart : everything not related to USB dev cart is removed, so that cartridge can be re-routed in a "clean" way.
It is basically similar to rev3 PCB made by antime, but with PCB routed by myself

"Rev 2e" cartridge.	Another "Rev 2e" cartridge.
Still another "Rev 2e" cartridge	"Rev 2e" cartridge, with only Flash ROM chips populated.

Saturn Cartridge - Rev 2f PCB Design : Aug. 2014

PCB designed in the same time as Rev 2e. This PCB focuses on Gamer's Cartridge, with also the ability to do some debug things over USB in the same time.
Rev 2a was used as a starting point, and USB module was put outside of CPLD, because I wanted USB to work even in the case logic in CPLD is incorrect.
As a consequence, CPLD is smaller than the one used in Rev 2a, hence easier to solder
Also, I put an edge connector on the top of the cartridge : main purpose was to easily connect debug gadgets (example : logic analyser).
I prefer edge connector rather than through hole one, since edge connector allows to connect multiple wires on a same pin, and is easier when having to remove the wires.
Sadly, SD card register map wasn't fully decided when routed the PCB, and stupidly I didn't routed CS1 signal to CPLD
As a consequence, a small rework (yellow wire on my Rev 2f cartridge picture below) is required in order to access SD card in the same way as Gamer's Cartridge's.

"Rev 2f" cartridge, used as USB dev cart.

My own "Rev 2f" cartridge.

Gamer's Cartridge - Rev 3.1 PCB Design : July-Aug. 2015

SD card access with Rev 2f cartridge was showing good results, so I decided to design Gamer's Cartridge alpha version
Goal for this PCB was "fit in official memory cartridge case", "standard (not micro) SD card socket" and "no debug stuff".
Designing custom footprint for SD card socket was a pain for a beginner like me, but printing out PCB layers in order to verify for real if footprint is correct or not helped a lot
PCB routing was the easy part : just removing useless stuff (SRAM, debug connector, USB module) from Rev 2f schematics was enough to do the job
For some reason, I initially thought that putting SD card socket on PCB rear side was a good idea ... but after soldering the first cartridges, I realized that putting SD card socket on front side would be even better ^^;
I first planned to order PCBs in standard green color only, but parcel containing theses PCBs was lost somewhere between manufacturer and my home. So re-ordered theses PCBs ("Rev 3.1 (a)", dated August 2015) in blue color, and few days after that, PCB manufacturer re-produced PCBs lost in initial order (green color, July 2015).
Blue PCBs arrived here first, and consequently first Gamer's cartridge I populated was a blue one, dated August 2015
Soldering blue PCB wasn't as easy as green ones (it was more "sticky" as usual), so I don't plan to use blue color in future PCBs. If you own one, you're lucky

Gamer's cartridge "Rev 3.1" Preview just before ordering the PCBs

Gamer's cartridge "Rev 3.1" in white Action Replay cartridge case

Gamer's cartridge "Rev 3.1" Detail on SD card slot

Gamer's cartridge "Rev 3.1" with SD card inserted

Gamer's cartridge "Rev 3.1" (The first one made ?)

Gamer's cartridge "Rev 3.1", rear side.

Gamer's Cartridge - Rev 3.2 PCB Design : July 2015

PCB designed in the same time as Gamer's Cartridge Rev 3.1. Purpose was to debug Gamer's Cartridge firmware, so it's basically a "Rev 3.1 + USB dev cart" cartridge.
I didn't wanted to spend a lot of time in designing it, so I "just" fixed the Rev 2f (= routed CS1 signal to CPLD) and removed useless things such as SRAM chip

Gamer's cartridge "Rev 3.2"

Gamer's cartridge "Rev 3.2", rear side.

Gamer's Cartridge - Rev 3.3 PCB Design : Jan. 2016

Gamer's Cartridge Rev 3.1 debug was progressing well (at that time, few games were compatible with Virtual Memory Cart ), so I removed the remaining debugs things from PCB (test pads around SD card, jumper, SMD LEDs), and moved the LEDs from the cartridge label area to a more appropriate location.
Also, SD card socket was moved from PCB rear side to front side, and positioned as deep as Action Replay cartridge case is allowing to.
And, I added an extra cow logo on the PCB, from new "pixel art" image, and rendered by using copper layer and solder mask

Gamer's cartridge "Rev 3.3" Sticker removed

Gamer's cartridge "Rev 3.3" Detail on SD card slot

Gamer's cartridge "Rev 3.3" with SD card inserted

Gamer's cartridge "Rev 3.3"	Cow logo added on Gamer's cartridge "Rev 3.3".
Gamer's cartridge "Rev 3.3", only SD card socket populated	Gamer's cartridge "Rev 3.3" and its cartridge case.

Gamer's Cartridge - Rev 3.3 (a) PCB Design : Feb. 2016

Nothing really special in this revision : I just moved the LEDs a bit, and ... it wasn't at the position expected I will re-re-move the LEDs by a couple of milimeters in the next revision, and hope it will be the last time I have to move them

Gamer's cartridge "Rev 3.3 (a)" Sticker removed

Gamer's cartridge "Rev 3.3 (a)" Detail on SD card slot

Gamer's cartridge "Rev 3.3 (a)" in white Action Replay shell

Gamer's cartridge "Rev 3.3 (a)"	Gamer's cartridge "Rev 3.3 (a)", rear side
Gamer's cartridge "Rev 3.3 (a)", LEDs position (I wanted theses to fit in case's gutter ...)	Another Gamer's cartridge "Rev 3.3 (a)"

Gamer's Cartridge - Rev 3.3 (b) PCB Design : July 2016

Still nothing really special in this revision : I just moved the LEDs a bit, and ... they were at the position expected
There are nothing left in my TODO list regarding Gamer's Cartridge PCB design, so this is very probably Gamer's Cartridge's last PCB revision

Gamer's cartridge "Rev 3.3 (b)" with "Cassini" label and black shell

Gamer's cartridge "Rev 3.3 (b)" with "PCB" label and white shell

Gamer's cartridge "Rev 3.3 (b)" with "CDROM" label and black shell

Gamer's cartridge "Rev 3.3 (b)" with "Deza_White" label and black shell

Gamer's cartridge "Rev 3.3 (b)" with "Deza_Black" label and white shell

Gamer's cartridge "Rev 3.3 (b)", front side

Gamer's cartridge "Rev 3.3 (b)", rear side

Gamer's cartridge "Rev 3.3 (b)", red PCB (The first red PCB I soldered !)

Even more colors ! It's a long time I didn't soldered blue PCBs

Gamer's cartridge "Rev 3.3 (b)" with "Deza_White" label and white shell

Gamer's cartridge "Rev 3.3 (b)" with "Deza_Black" label and black shell

Gamer's cartridge "Rev 3.3 (b)" with "CDROM" label and white shell

Gamer's cartridge "Rev 3.3 (b)" with "PCB2" label and black shell

Gamer's cartridge "Rev 3.3 (b)" with "Cassini" label and white shell

USB dev cart - Rev 3.4 PCB Design : July 2016

Minor changes from Rev 2e consisting in adjusting PCB shape in order to make it fitting in Action Replay shell.
I also catched this occasion in order to "pixel art" cow logo, identical to the one used in Gamer's Cartridge
Additionally, this is the first USB dev cart revision shipped with custom label and Pseudo Saturn Kai firmware.
It took around four years between first USB dev cart assembly and this "ready to use, user friendly" revision, but I did it Big thanks to all concerned people for label design and printing as well as people who helped in Pseudo Saturn Kai development

USB dev cart cartridge, custom label and black shell.

USB dev cart cartridge, 3D rendered from PCB design software.

USB dev cart cartridge, custom label and white shell.

USB dev cart "Rev 3.4", unpopulated PCB, front side

USB dev cart "Rev 3.4", unpopulated PCB, rear side

Wasca - Rev 1.2 (a) PCB Design : July 2016

My first try in doing a Wasca cartridge
I used Wasca revision 1.1 as a base for developing PCB, and since I'm very interested in Wasca's main chip (MAX 10 FPGA, EQFP144 footprint) I kept it as-is, and removed secondary chips, such as STM32, and external connectivity related chips
Additionally, I changed PCB shape to the one used in Gamer's Cartridge, so that it would fit in Action Replay shell, but because of MAX 10 chip dimensions, I had to move the SD card socket a little bit.
And of course, I added my favorite cow logo on the PCB. Thank you Sim for designing it

Also, I added connectivity for same USB interface as the one used in USB dev cart. It is not put directly on the cartridge, but available on a separate mezzanine board, because there wasn't enough space on cartridge PCB, and also because mezzanine board can be re-used from a prototype to another.
USB interface is mapped directly to Saturn's A-Bus, so direct access to cartridge RAM from PC isn't possible and requires usage of Saturn's SH2 CPU to access. IMHO this isn't a major limitation, and direct access from PC to MAX 10 isn't possible because of I/O pins limitations.

I populated one cartridge, could flash MAX 10's firmware a couple of times ... and couldn't flash anything after that This is probably due to my poor soldering skills regarding EQFP144 footprint.
I wasn't actually expecting this first prototype to work This was "just" an occasion to try EPFP144 soldering, and getting used with Wasca's firmware compilation and flashing

Wasca Rev 1.2 (a) unpopulated PCB, front	Wasca Rev 1.2 (a) broken prototype, front
Wasca Rev 1.2 (a) broken prototype, rear	Wasca Rev 1.2 (a) unpopulated PCB, rear

Wasca - Rev 1.2 (b) PCB Design : July 2016

Not a cartridge, but a mezzanine board for Wasca Rev 1.2 (a), featuring same USB interface as the one used in USB dev cart.
Because first (and so far, only) Wasca Rev 1.2 (a) prototype no longer works, I didn't finished to populate this mezzanine board, but plan to use it someday when I will need some USB connectivity

Wasca Rev 1.2 (b) unpopulated PCB, front

Wasca Rev 1.2 (b) unpopulated PCB, rear

Wasca Rev 1.2 (b) half-soldered, front

Wasca - Rev 1.2 (c) PCB Design : October 2016

Still not a cartridge, but a MAX 10 evaluation board. Official MAX 10 evaluation boards are either too simple (without external RAM) or too complex and expensive, so I tried to design one with same parts as the ones used on Wasca Rev 1.2 (a).
So basically that's Wasca Rev 1.2 (a) without cartridge connection to Saturn : the interest of such evaluation board is to focus on development not requiring interaction from Saturn ("hello world" from MAX 10, making LEDs blinking, accessing files on SD card, etc), and also continue training on EQFP144 soldering.
If firmware development goes far enough, I plan to make an "interface cartridge" to plug between this board and Saturn in order to start development of Saturn related things.

Wasca Rev 1.2 (c), front preview from PCB design software

Wasca Rev 1.2 (c), rear preview from PCB design software

Wasca Rev 1.2 (c) populated and ready for testing

MAX 10 Board - Rev 0.5PCB Design : January 2018

I froze Wasca project during 2017 to put priority on ongoing Saturn software projects such as Saturn Floppy Disk support on Pseudo Saturn Kai, cheat codes, etc, but up to some point I really wanted to give some progress to Wasca, so I added some modifications Wasca Rev 1.2 (c), whose most notable changes are the addition of a clock source and MAX3000A CPLD on the board.
This clock source is used as a replacement of clock signal from Saturn, and the MAX3000A simulates Saturn cartridge interface to ... basically do nothing except making MAX 10 happy regarding Saturn cartridge interfacing
Because of the addition of theses two elements simulating a Saturn, this is closer to a MAX 10 test board rather than a Saturn cartridge, hence the change of codename from "Wasca" to "MAX 10 Board".
This is not an abandon of Saturn cartridge project, but rather going backward to then give a better direction to the project My development strategy is to first focus on non-Saturn parts of the projects, and make rock-strong debug environment so that I would probably be prepared when problem(s) will happen when testing for real.

So far (as of June 2018), it is possible to do communication between PC and MAX 10 at speed fast enough for my needs. As usual in project engineering, it took me way more time to develop custom software (on PC side) and firmware (on MAX 10 side) to comfortably do communication, logging, debug etc tasks than designing this test board itself
Up to some point, SD card interface was replaced by SPI interface for addition of ARM microcontroller. Everything is still "work in progress" (not to say "working only when weather is clear enough" ) regarding ARM microcontroller interfacing, and I probably should design a cleaner test board regarding that someday

MAX 10 Board 0.5 itself

MAX 10 Board 0.5 in action. Foreground : USB converter communicating with PC. Background : debug software in all its glory.

MAX 10 Board 0.5, with ARM microcontroller.

Gamer's Cartridge - Rev 3.3 (c) PCB Design : August 2018

That's basically the same stuff as in previous PCB revision, but footprint for alternate voltage regulator is added.
This alternate voltage regulator is used in another project, and as I would like to unify parts used in my electronics components library, the regulator used so far will be dropped when stock will be emptied.
So in order to do a smooth transition between theses two voltage regulators, footprints for both regulators are put on the PCB, and the old one will be removed from the PCB on next iteration.

Additionally, pre-programmed CPLDs are used from this PCB revision : so far I was programming the CPLDs one by one after populating each board. Thanks to pre-programming the CPLDs, this step is no longer needed so that populated boards can directly go to the "mount into shell" step, thus saving some little time on my side

Gamer's cartridge "Rev 3.3 (c)" Preview just before ordering the PCBs

Gamer's cartridge "Rev 3.3 (c)", Green PCB, front side

Gamer's cartridge "Rev 3.3 (c)", Red PCB, front side

MAX 10 Board - Rev 0.7PCB Design : August 2018

Firmware development for my MAX 10 board v0.5 went better than expected : there was not enough remaning logic available on MAX 10 side to add a decent way to communicate with STM32 microcontroller.
I own two kinds of MAX 10 chips in my library : 10M04SC and 10M08SC. 10M08SC have twice more logic available, but is also twice more expensive, and not always available for purchase too. So when populating my MAX 10 board v0.5, I thought it would be another failed prototype and selected a cheap 10M04SC
And instead of populating another same board with 10M08SC, I thought it would be a good occasion to design a new board more suitable with the needs that arised from v0.5

- Integration of serial to USB converter
- "Clean" support of STM32 microcontroller
- PCB layout designed to fit in a plastic box
- Enough logic to simulate access on MAX 10's Saturn interface

---

Serial to USB converter : MAX 10 board v0.5 was using external serial to USB converter, as displayed in the right half of the following image.
Such kind of external converter is cool for prototyping, but this makes test board messy with wires going from here to there. I don't like that, so it was a pleasure to add extra circuitry for it

---

STM32 microcontroller support : with MAX 10 board v0.5, STM32 evaluation board was connected to MAX 10 ... by hacking SD card connector Moreover, connection on STM32 board side was done with jumper wires, which are cool for testing during one weekend, but may get out of place after a longer period of time, especially in a messy development environment
To prevent that, socket for receiving STM32 board as well as through hole connections are added on MAX 10 test board. This provides a simple way to connect STM32 with other parts on the board, and is also reliable too since I plan to do in-board connection by soldering wires rather than using loosy wires connectors.
Additionally, using a socket to receive STM32 board makes the thing plug and play, which may be helpful in the case the microcontroller must be changed during development : I honestly don't have any idea of which microcontroller is suitable for the project, so I just started with the one laying in my parts library, and shall use a larger one if required

---

Plastic box compatibility : in compliance with ISO-1664 standards (), previous test boards had their shape designed as a big rectangle, with the hope that some time would remain to adapt shape to a fancy prototype box between the end of PCB design and sending it to PCB manufacturing house. This way of managing development schedule NEVER worked , so I took the problem by reverse and organized PCB shape and main components layout before starting PCB design
This resulted in significantly longer design phase (around 6~7 weeks IIRC ), but I'm proud of the result ! Well, so far (2018/09/02, waiting for PCBs to be manufactured), I just tested with prints on paper, and hope everything will be allright for real
I choose plastic box for 3.5" HDD for some simple reasons : shape and position of the screws is standard, so I may not run out of spare plastic boxes in the future. Additionally, thanks to a large PC peripherals maker who designs classy boxes but uses crappy HDD inside, I hoarded many empty boxes during the past few years, so it would be a waste not to re-use theses in my projects

As a result of using 3.5" HDD box, PCB dimension was the largest designed so far ... and so was the manufacturing price too. So let's hope I didn't forgot anything when designing the this board

MAX 10 Board 0.7 (print test v1) It's time to change printer ink cartridge

MAX 10 Board 0.7 (print test v3) Can you find the differences with v1 ?

---

Saturn interface simulation : still in compliance with ISO-1664 standards, previous test board was designed with a MAX3000A CPLD near MAX 10 in the hope it would be sufficient to simulate access from USB port to MAX 10's Saturn cartridge interface.
And well, as usual this was a complete failure, because it looks like one MAX3000A is just enough to do Saturn signals multiplexing job, but not enough to do USB connectivity in the same time.
Real hardware developers do resource estimation when deciding hardware architecture, but as a software guy doing electronics during weekends, I don't have such kind of skills, so put probably enough MAX3000A on this board : from initially one MAX3000A, it evolved to three, and with also fast (but small) RAM chip too.

On potential question about this simulator is "why using such wacky MAX3000A architecture and not another MAX 10 instead ?" The reason is simple : I'm more at ease with MAX3000A devices : compilation time takes less than one minute on my dev laptop (vs 10 minutes with MAX 10 ...), and so far I made one working project with MAX3000A, which is not the case with MAX 10. Since this simulator will be used as reference for MAX 10 firmware development, it is reassuring to use MAX3000A

Purpose of this simulator is to be able to hardware-level debug without having to plug to Saturn, connect to TV, etc. In fact, I have several time slots available for outdoor development, but not a lot in front of my Saturn, so if this board fits in plastic box, it would become my favorite companion for firmware projects development

---

MAX 10 Board 0.7 (2018/07/30) Still very similar with v0.5	MAX 10 Board 0.7 (2018/08/25) Before filling with ground vias
MAX 10 Board 0.7 (2018/08/29) After tidying up a little the board	MAX 10 Board 0.7 (2018/08/31) Preview from PCB manufacturer

MAX 10 Board 0.7 (2018/09/29) SD card socket will be populated when other parts will work correctly enough

MAX 10 Board 0.7 (2018/09/29) With STM32 microcontroller board. Codename : the USB monster

---

Hardware / Firmware / Software Development Log 2018/08/30 : PCB routing done and will be sent to manufacturing house the next day.
My goal was to finish this in August ... I'm tired, but glad the job could be done in time
2018/09/15～ : PCBs and electronic parts received ! It's time to start the assembly of one test board
2018/09/29 : Soldering and preparation of plastic box finished. I wasn't used to such insane total pins count (around 600 pins !) so that soldering took a bit longer than planned.
And total cost for this board was in the $100-ish range (the MAX 10 itself costs $40 !) so that was a lot of pressure not fail board assembly
2018/10/03 : Some unexpected troubles during development of firmware for MAX 10 : minor changes in assignment of (nearly) unused pins make MAX 10 soft CPU program not booting correctly Additionally, MAX 10 external RAM reports error during memory testing too. The memory test problem is probably a software bug, but I honestly don't have any idea about that pins assignment issue.
I was probably too greedy when deciding to use this expensive MAX 10 chip, so it should be good to make another board with a MAX 10 equipped with more reasonable amount of resources and see if problem happens again or not
And I'm not that confident with my soldering skills for such fine-pitched parts, so it would be good to ask somebody more competent for assembling this second board
Theses are unexpected development cost, but I was ... expecting something unexpected to happen ... I still have few Gamer's Cartridges in my cartridge stash, so it's the good moment to sell them
Additionally, it would be a good occasion to focus on firmware/software development for MAX3000A chips (the three smaller ones at right side of the board) in the meantime if I can parallelize board assembly
2018/11/06 : After many tries and failures, I finally could get some communication between MAX 10 and STM32.
Communication speed is an outstanding ... 5KB/s, which is around one percent of my goal for Wasca
Well, it seems it's the time of taking out logic analyzer to see what is slowing down the communication

MAX 10 Board 0.7 (2018/11/04) With STM32 microcontroller board, a bunch of USB devices and logic analyzer. The USB monster is growing

2018/11/10 : SPI works a little better at around 350 KB/s, and it may be improveable with appropriate design of communication between MAX 10 and STM32
BTW, the 5KB/s in last update was mainly due to a "wait 50 for milliseconds between two transfers" debug stuff on STM32 side that I forgot to remove when measuring transfer speed
Except that, STM32 is now able to do SPI with DMA transfer, so that it is relatively fast and have negligible impact on CPU
On MAX 10 side, SPI transfer monopolizes CPU, but this way of doing should be all right for a while.

MAX 10 Board 0.7 (2018/11/04) With still a load of USB gadgets connected. Yes, I enjoy debugging in my car

Messy bunch of softwares on my favorite dev laptop which make debug and testing jobs getting done. "It works, trust me I'm an engineer"

2019/07/17 ... summary of what was done between March and recently :
STM32 memory access from MAX 10 now works, which enables some (limited) debugging
Additionally, the ability to retrieve logs from PC via MAX 10 should be now possible (*) by using this same memory access set of commands. This will allow fast logging and also to gather logs from both MAX 10 and STM32 in a same debug program via the same USB cable too.
My biggest pride in this achievement is that it didn't required any change on MAX 10 side : access to log data was "just" mapped to a special address (STM32 is full of "reserved" address ranges, so it was a pleasure to use use one for my needs) and PC is then accessing it via MAX 10 as a normal address.
→ This is important because MAX 10 have limited resources which consequently need to be used carefully : I hope a $20 device will fit my needs, but if that's not the case then device price will jump to $40 ...
→ On the other hand, while STM32 doesn't allows to implement custom logic circuits (which is the strong point of MAX 10), it is tailored to execute complex and large programs so that I gladly implemented log messages access on it.
(*) The should be now possible must be taken with a high pinch of salt : so far I just verified that logs access was working fine with unit testing and then implemented log acquisition and display on PC side but didn't yet had time to test everything on real hardware.
I don't expect things to work on first try (so far, everything I made never worked correctly on first try !), but after some time spent in investigations and debugging, things will work as expected. Trust me, I'm an engineer !
2019/07/21 :
The superb MAX3000A-based simulation interface showed how well it was designed in compliance with ISO-1664 standards : logic available on theses tiny CPLDs is completely unsufficient to do anything special from PC
As in the meantime SIM development was going (more or less) well, I decided to design an interface board to connect SIM to MAX 10 : this have the advantages of re-using PC software and MAX 10 firmware for SIM, and being a relatively economical solution since a small interface PCB costs around three times less than one for a new revision of MAX 10 Board, and also because as this is just an interfacing solution between two existing boards, it doesn't costs any electronic components.
Except this shiny planning, everything else didn't went very well () : after ordering the PCBs, I realized that signal would transit at 116MHz between MAX 10 and interface board and consequently may not work as expected because of signal glitches occuring at such speed over physical wires. Fortunately there was a B plan to re-use a MAX3000A on MAX 10 Board to do the 116MHz job so that signal on physical wires would "just" transit at maximum 22.5MHz.
Then, I realized I made a big mistake while assembling the mass of wires between theses two boards I would had been surprised things would work fine after terminating this spaghetti artwork ! And ... I wasn't surprised to see that data retrieved via SIM from Wasca's A-Bus interface was a complete garbage
To finish on a positive note, I would say that it was an occasion to verify that theses two solutions would do something (other than not booting or producing smoke) together.
I'm still stuck on fixing things regarding cartridge RAM access for Wasca, and still do believe that preparing a proper MAX 10 Board to test that is the best solution, so maybe it is the right time to prepare next generation of MAX 10 Board ? This requires a lot of time (to design and assemble such kind of board) and money too ($70 for the PCB, $40 for two MAX 10 FPGAs, ~$20 for the other parts etc) so it's not an easy thing to decide. On the other hand it may also worth to persevere a bit in getting this spaghetti working : so far I just tested it only a little because assembly and pins assignment between theses three devices (MAX3000A and MAX 10 x2) took all my free time before that

MAX 10 Board 0.7 (2019/07/21) connected to SIM.

Wasca - Rev 1.3 PCB Design : August 2018

Second real attempt regarding Wasca cartridge : first attempt was a complete failure, but MAX 10 board v0.5 worked a little, so it's time to take a revenge
Additionally, my friend XRider showed some interest to previous prototypes boards made so far, and even wants to give an hand in assembly, which helped me to escape from the "I'm too old for this shit" state I was regarding Wasca during the last two years

About changes in hardware ... well, there's nothing really special : I just changed USB dev cart support to serial communication with PC. This will result in slower communication with PC hence may look like a regression, but USB dev cart requires many signals for interfacing (around 12 signals for USB dev cart, vs 2 for serial), which was making routing a bit messy.
Moreover, serial communication provides a way to access MAX 10 internals, while USB dev cart is limited to Saturn's. Main goal of this PCB revision is to test wasca stuff, so it's certainly a better choice to use serial communiation right now

Regarding PCB routing, it was an occasion to improve a little regarding ground covering around 5V/3V3 buffers, and to change footprints for resistors from "handsoldering" type to the footprint used in USB dev cart and Gamer's Cartridge : "handsoldering" footprint sounds good for hobbyist like me, but it's so large that it's hard to be sure if resitor is correctly positionned at the center of the soldering pads or not The usual footprint is maybe a bit small, but at least I'm used to it

The goal for this board is not to develop final version of Wasca firmware, but rather to verify if interfacing with Saturn works or not : if I can get external SDRAM accessible from Saturn, this will be a good milestone.
Optionally, I will see if SD card access can be added or not : the libraries provided by Altera are quite minimalistic, so may require some extra work around ... or rewrite everything from scratch as usual
Another challenge would be to add USB dev cart emulation from serial interface. This requires changes on PC transfer utility (SatLink), which shouldn't be a problem for me, and also the emulation of USB dev cart registers on cartridge CPLD side. I'm not that strong with this latter half part, but this will be a occasion to play with firmware sources which so far I was keeping untouched from hitomi2500's version

... Arg, while writing this description, I realized that R152 (located near USB connector) value is not correct : it should be 4.7K Ohhms, and not 10K as indicated This will be fixed in next PCB iteration
In fact, it was initially not scheduled to develop this board : I wanted to send MAX 10 board Rev 0.7 for manuacturing to my favorite PCB house until August 31st because ... they were offering discount coupon until this date to celebrate Seeed Studio 10 years birthday
So I rushed to prepare MAX 10 board Rev 0.7 board in time, and around 2 days remained until the deadline, so I used theses to design this version
However, when initially reading discount advertisement email, I thought it was "20% off for orders over USD100", but it seems I mistook with "USD20 off for orders over USD100" This discount is not as good as expected, but mistaking about it was good because this motivated me to finish this PCB design marathon

Wasca Rev 1.3 (2018/08/31) Preview from PCB manufacturer

Wasca Rev 1.3 (2018/09/15) The PCB for real

---

Hardware / Firmware / Software Development Log 2018/10/22 : One cartridge is assembled (Thank you XRider ), and another one with smaller MAX 10 is about to be assembled.
Cartridge first needs complete testing of each pins to be sure it won't cause problems during first power-on, so patience it required before actually seeing it working ... if by chance it works
MAX 10 Board firmware development takes priority, so there's currently no firmware available for this cartridge.
Additionally, I forgot to unify pins assignment with MAX 10 Board, which shall be done in next PCB iteration, so this is far from being final PCB revision for Wasca project.
Anyway, let's try and see if this cartridge works or not. A nice milestone would be to get 32MB expansion RAM available from Saturn. And I really want to take revenge over the problems I had with Wasca Rev 1.2

Wasca Rev 1.3 (2018/10/22) Assembled by XRider

2019/07/17 ... summary of what was done around March and April :
Interfacing between Saturn cartridge bus and Wasca works. There was some pins assignment issues (on all address pins ...) which could be detected and countermeasured
In order to test access to cartridge RAM, I developed a memory test program which shows that cartridge RAM access works well ... during oneshot access only. During burst access, data is sometimes lost or not written correctly
→ Let's take things positively and consider that at least it made sense to develop this cartridge memory test program for Saturn !
This kind of problem with data being corrupted at random times smells symptoms of something missing between Saturn cartridge interface and memory controller on Wasca firmware side, which needs some additional investigation and also maybe reading few MAX 10 technical documents
But, rather than modifying firmware and testing on Saturn endlessly, my plan is to get able to simulate cartridge access on MAX 10 Board, fix the problem there and finally port it back to Wasca.
→ Main reason for preferring MAX 10 Board is that I can use it way more frequently than Wasca + dev Saturn. Also, hoping that things will work straight at first try on such a complex gear like Saturn hardware is usually like playing Russian Roulette with 5 bullets (don't try that ) : it is safer to first do unit testing in an environment where input and outputs are controlled, and deploy changes for testing on real hardware after verifying that unit tests went fine.

Memory Test on Wasca Rev 1.3. Corrupted ROM header ... Never expect things to work on first try

Memory Test on Wasca Rev 1.3. Expected signature at expected address. At least data and address interfacing works

2020/01/25 : One year and half ago, my friend XRider kindly provided me two cartridges : the one with 10M08SC FPGA used so far, and another one with a smaller 10M04SC FPGA. As this second cartridge was not completely populated and doesn't provides anything special over the larger one, it was shelfed until I actually need it.
I still don't really need this cartridge, but as I had some (limited) spare time, I took the occasion to finish to populate it Because this FPGA have limited resources, only the bare minimum was soldered and consequently USB connectivity as well as SD card are left blank : main interest of this prototype will be to test SDRAM access and ... to exist so that I will not have to solder a prototype for that in the future.
After soldering, I did minor verifications on it with SIM and it seems it works fine : at least the LED blinks and external memory can be read and written

Wasca carts populated by XRider. Left : smaller and incomplete one with 10M04SC FPGA Right : the one with 10M08SC FPGA used so far

USB dev cart - Rev 3.4 (a) PCB Design : October 2018

A friend wanted a spare USB dev cart, and as I stopped USB dev cart manufacturing I still had some Rev 3.4 spare PCBs in stock.
I however preferred to order another a new batch of PCB to test if my favorite PCB manufacturer would notice the instructions written on the PCB and do edge bevelling on cartridge connector. Fortunately the PCBs arrived with requested shape so that it is (for a while ?) the last USB dev cart PCB iteration
Additionally, this was the occasion to -finally- indicate version information near edge connector so that it is possible to verify PCB revision without having to open cartridge shell

I botched a little the first PCB because of trying to fix a solder bridge that ended in damaging a pad under a flash chip pin. Such kind of problem doesn't happens frequently, so I took a picture for the occasion. Fortunately it was easy to fix thanks to parallel usage of flash ROM chips in this cartridge
I sometimes (one or two per year) make "functional, but after repairing" cartridges and put theses for sale at reduced price and after informing future user about what was fixed, but in this case I didn't planned to charge the friend for this cartridge so everything is fine

Maybe I was a bit rusty after a long time without preparing USB dev cart, but the assembly of this cartridge took way longer in comparison with Gamer's Cartridge I don't have any regret to have stopped production and support for this kind of cartridge.

USB dev cart "Rev 3.4 (a)", unpopulated PCB, front side

USB dev cart "Rev 3.4 (a)", unpopulated PCB, rear side

USB dev cart "Rev 3.4 (a)", ready for flashing Pseudo Saturn Kai

USB dev cart "Rev 3.4 (a)", detail on edge connector, indicating version information

Gamer's Cartridge - Rev 3.3 (d) PCB Design : October 2018

The continuation of PCB revision 3.3 (c), with old voltage regulator circuitry removed.
This was also my first occasion to test PCB assembly service from my favorite PCB manufacturer. Well, it was actually "half-manufactured" because some parts are not compliant for PCB assembly service : CPLD and SD card socket are obsolete hence can't be easily supplied, and additionally the decoupling capacitors were soldered on my side since it's more convenient to solder theses after the CPLD.
Whatever it may be, this saves some time on my side, especially regarding the flash ROM chips : PLCC-32 footprint is boring to solder, and I have to solder two of theses chips per cartridge
PCB assembly price was so-so, but that was because of the relative simplicity of the PCB and parts used, and also because of the small quantity I ordered : I suppose it is more advantageous with more complex and larger scale projects

Additionally, this PCB revision is the first one to -finally- indicate version information near edge connector so that it is possible to verify PCB revision without having to open cartridge shell

Gamer's cartridge "Rev 3.3 (d)", pre-assembled PCB, front side

Gamer's cartridge "Rev 3.3 (d)", pre-assembled PCB, rear side

Gamer's cartridge "Rev 3.3 (d)", ready for flashing Pseudo Saturn Kai (Trivia : the 4.7μF capacitor is missing on the picture)

Gamer's cartridge "Rev 3.3 (d)", detail on edge connector, indicating version information

SIM - Rev 1 PCB Design : February 2019

As its name suggests, SIM's main purpose is to simulate access from Saturn on a cartridge : this was designed in the hope it would be useful in development of Wasca.
To achieve this goal, SIM was designed to allow access to any kind of cartridge, and to be controlled from PC : test pattern is indicated in a text file, and PC can repeat the same test over and over to be sure that everything is still OK even after one million iterations
→ At a glance, testing cartridge development directly on Saturn seems the best solution, but simple tests (such as accessing specific memory addresses, at specific speed, etc) aren't easily possible in that case.
→ My philosophy about hardware/firmware/software development is to first prepare a strong basis by using simple tests in an isolated environment and then to fight remaining unexpected bugs on real hardware. Because from my own experience, testing directly on real situations never works

At some point SIM assembly was terminated, but unfortunately things didn't went as expected : while access to Gamer's Cartridge was OK, it was completely messy with Wasca and Action Replay cartridges Unlike other ones, Gamer's Cartridge doesn't uses all address pins (upper ones are ignored), so my guess about this trouble is that some pins around address upper bits are not correctly connected to cartridge ?

Rather than trying to fix SIM, I realized how messy to do tests on SIM + a cartridge connected on it in my main development environment = my car So my development environment needs evolved to both SIM and Wasca architecture on a same PCB, protected in a case like MAX 10 Board !
This requires a bit of money : a large PCB (like the one in MAX 10 Rev 0.7) itself costs around $100 for manufacturing + shipping, and additionally around $60 are required for electronic parts.
So rather than hurrying in making the next generation of SIM and MAX 10 Board, I will do my best to use existing ones as far as possible, record the details that needs to be improved and finally prepare the ultimate (?) MAX 10 Board when the right moment will come

Globally speaking, I consider this iteration of SIM more than half a success, because it was the occasion to start development of its firmware (it uses a MAX 10 FPGA, like Wasca), and can be used to power on and provide clock signal to cartridge, which is enough to do basic things with Wasca, such as firmware update, and then verify everything not related to Saturn cartridge port so as USB connectivity, external memory test, etc.

SIM Rev 1. Top : cartridge connector board Bottom : interface with PC

SIM Rev 1 : usage example when dumping Gamer's Cartridge ROM.

---

2018/09/28 : Almost finished to prepare FPGA board for a second SIM !
The interest to prepare such board is to re-use initial FPGA Board for the needs of ongoing prototype, and use a smaller -but large enough to do the job- MAX 10 for SIM itself.
In technical words, SIM now uses a 10M04 device and 10M08 device initially used is now reserved for MAX 10 Board Rev 0.7 (b). That's twice more logic (and a bit more RAM too) to face unexpected problem(s) that shall arise in next prototype

Also, the USB port connected to FT245 chip is not populated for SIM because I currently plan to use FT232 only and also because a 10M04 device may not have enough resources for handling another communication port.
Preparing this FPGA board was a bit adventurous because first try was a miserable failure which became bricked after flashing it a couple of times I'm not really sure of what bricked the board, but maybe it was caused by applying too much heat on the the chip when soldering it.
Second try was soldered with a older iron which seems more suitable for fine pitched TQFP chips. So the board is not bricked so fortunately things went better that time

The "almost finished" status is because after I thought drilling of the case was terminated and tidying up the tools, I realized that ... I forgot to open an hole for LEDs
Also, USB cable used for supplying power broke during the very last time of that day Cause of this problem is a design failure of FPGA board because it lacks of holes to hold power supply cable : twisting the cable even a little causes enough tension to break it. I shall prepare an extra power supply board to fix that problem

Finally, as 10M04 chips are relatively affordable I started to prepare a third FPGA board in parallel of the second one.
But as the second one went fine I shelfed this third one but shall use it in the case second board breaks or in case of need in a future project
2018/10/07 : Before designing a foolproof power supply board, I re-soldered the power supply cable so that this SIM can be used at any time even in case of sudden need Main application I plan for it is to flash MAX 10 firmware, and to do minimalistic behavior verification; cartridge connector can't be reliably used, but cartridge's USB connectivity is OK so that at least it's possible to verify if NIOS executable (the program stored into MAX 10 FPGA) boots.
I also catched the occasion to open an hole for the three status LEDs. Because I didn't used any guide for the LEDs in this board (the right-angled ones used in the 10M08 SIM board are not really cheap), the result is so-so, but at least the LEDs are visible, which is the most important.

Gamer's Cartridge - Rev 3.3 (e) PCB Design : February 2019

As usual, nothing really new from PCB revision 3.3 (d), in this PCB iteration.
The main change in the PCB routing is the rotation of the 0.1 μF capacitor near voltage regulator circuit : the interest of doing that is to get all theses 0.1 μF capacitors in the same orientation hence making their soldering a bit simpler for me.

Another visible change is the lack of "don't forget chamfering" indication in Chinese on PCB : it is still present on PCB design files, but PCB manufacturer removed them before production so that result looks more classy than in the previous iteration I didn't asked for that so it was a good surprise to see the result when receiving the PCBs

And, unlike PCB revision 3.3 (d), this batch of cartridges doesn't uses PCB assembly, but only unpopulated PCB manufacturing service. I'm quite happy with PCB assembly service and the reason I didn't used it this time was simply to save a bit of my pocket money

Summer 2019 update : Seeed Studio was offering all extra internal costs for PCB assembly service so I jumped on the occasion ! This is limited to 5 PCBs which are indicated with "PCBA" version information indicated near cartridge connector. This saved a significant amount of time on my side, which was spent on Wasca related things

Gamer's cartridge "Rev 3.3 (e)", front side

Gamer's cartridge "Rev 3.3 (e)", half populated PCB, front side

Gamer's Cartridge - Rev 3.3 (f) PCB Design : June 2021

Apart maybe a couple of minor details I forgot, that's the same thing as PCB revision 3.3 (e) but with several "don't forget to chamfer the edge connector" messages written on the PCB.

Gamer's cartridge "Rev 3.3 (f)", front side

MAX 10 Board - Rev 0.7 (a)PCB Design : August 2019

Back in 2018 when I designed MAX 10 board Rev 0.7, I was trying to use simple but outfashioned MAX3000A CPLDs to simulate A-Bus access from Saturn.
And, this was a complete failure In the meanwhile of developing the firmware for theses MAX3000A, I realized that there wouldn't be enough logic on theses small CPLDs to handle all Saturn signals. Additionally, all the software on PC side (to indicate which data and address to access, etc) had to be written from scratch in an unusual fashion, but because of the lack of hardware logic, writing such kind of software would only do limited actions on a limited range of signals.
So instead of wasting time for an half-baked goal, I spent more time on SIM, which was simpler to develop on PC side (because it re-uses things done during MAX 10 Board Rev 0.5 development) and gave results good enough to replace this cluster of small MAX3000A CPLDs with something working better.
And of course this was also the occasion to add improvements on some little details :

- Right side of the board shape adapted to the box used : I was too lazy to do it properly in MAX 10 board Rev 0.7 but didn't had any excuse to botch the artwork this time
- Better connectivity regarding power supply, which now allows to supply the board from micro USB connector.
- Rationalized connectivity around SD card. It should be simpler to debug this !
- Some LEDs changed to smaller (SMD) type, because theses were colliding with box when closing it ...
- Spare SD card socket directly connected to SIM's MAX 10 FPGA. This is to test direct SD card access from MAX 10 in the case it makes sense to develop a Wasca without STM32 microcontroller.

Initial plan to design this board was to remove the MAX3000A CPLDs and to replace theses with same stuff as SIM ... at first glance this looks simple but this ended in re-designing more and than half of the board I'm happy that the re-design is finally done, but this exhausted me enough to be sure that I certainly won't re-do that soon

---

MAX 10 Board 0.7 (a), 2019/09/19 Preview before sending to PCB manufacturer

MAX 10 Board 0.7 (2018/08/29) For comparison with this iteration. Could you spot the 657 differences ?

---

Hardware / Firmware / Software Development Log End of August 2019 : PCB design file 99% complete.
2019/09/19 : Ordered manufacturing of the PCBs.
2019/10/03 : PCBs received !
I just verified that PCB fits in plastic box, and project is paused for a little while, in order to put priority on assembling and development of MAX 10 board Rev 0.7 (b)

MAX 10 Board - Rev 0.7 (b)PCB Design : September 2019

When designing MAX 10 board Rev 0.7 (a), I realized the project would be too large and and risky for what I usually can do, because there are two MAX 10 FPGAs on the same board which makes the whole thing harder to debug in case a problem happens, and requires to trash the whole (expensive) board if by mistake an electronic part is damaged during assembly or usage of the board.
Development of this second board was also motivated by the fact that the prototypes made so far fail at a relatively high rate. As a simple countermeasure, I thought that developing two boards at same time would improve this failure rate

For the reasons above, this board was developed with the following guidelines in mind :
Re-usage of SIM : starting idea of this MAX 10 Board iteration was to stack two MAX 10 Boards for SIM and "simply" add multiplexer and SDRAM on the top board. By doing this, any problem on a board shall not affect the other one, thus reduces the risks as well as prototyping costs.
Also, the first MAX 10 Board for SIM was assembled with a MAX 10 "10M08SC" device which is a bit overkil for SIM project. So my plan was to assemble another MAX 10 Board for SIM with a 10M04SC (smaller and cheaper device) and use the 10M08SC one for this MAX 10 Board Rev 0.7 (b). So before ordering the manufacturing of this board, half of the electronics was already soldered and working, which was quite relieving !
Using this 10M04SC for SIM was actually an occasion to free some space from my electronic parts library because I don't really plan to use such small device on Wasca
Small size : MAX 10 board Rev 0.7 (a) uses box for 3.5" HDD, which is a bit ... bulky. On the other hand, the shape of the cases used in SIM were fancy and convenient enough to decide to re-use the same cases for this iteration. That looks like a detail, but it's actually more motivating to use a neat test board rather than a big mess of wires
Simplicity : Complex stuff is for MAX 10 board Rev 0.7 (a), and the goal of this board is to get at least something working even if that Rev 0.7 (a) would fail. For this reason, I removed support for STM32 microcontroller as well as spare SD card socket and restricted this board to only essential modules.
Blaster-friendly : the JTAG connnector (where to connect the blaster cable to program a FPGA) for SIM is horribly positionned at around the center of the box, and for this reason I have to open this box every time I have to update SIM's firmware. Now that I know how annoying this kind of detail is, I did my best to make JTAG connectors accessible without having to open anything and also added room for a spare JTAG connector so that JTAG for SIM is now located at a convenient place too
Alternate Design : to avoid repeating any eventual design mistake in MAX 10 board Rev 0.7 (a), the multiplexer was implemented by using MAX3000A CPLD instead of two buffer gates. This have the extra advantage of being a more flexible flexible design which have more chances to be re-used in future project(s) of any.
Buffer gates toggle at very high speed, but I use a CPLD with high speed grade from my "special reserve" so that this CPLD-based solution should work.
And this time, the firmware was developed and simulated before ordering manufacturing of the PCB so that there won't be any bad surprise of board ready for testing but firmware not fitting inside the CPLD

Design of MAX 10 board Rev 0.7 (a) was roughly terminated at the end of August 2019, and as there was long holidays in China at the beginning of October, my favorite PCB manufacturer put a deadline on September 20th to get a small discount and -what's more important- PCB manufactured and dispatched before theses long holidays. So I rushed the design of this board in less than three weeks and ordered both r0.7 (a) and (b) at the same time on September 19th. Having such kind of deadline being setup is good because projects without concrete deadline can continue endlessly

---

MAX 10 Board 0.7 (b), 2019/09/19 Preview before sending to PCB manufacturer

---

Hardware / Firmware / Software Development Log
2019/09/19 : Ordered manufacturing of the PCBs.
2019/10/03 : PCBs received !
2019/10/05 : Both MAX 10 and MAX3000A devices as well as SDRAM and USB connectivity and few LEDs are soldered, so it's time to test if the devices fried during assembly or not After setting up them with firmwares to make LEDs blinking ... the LEDs blinks , so I'm currently the proud owner of a Christmas tree ornament
USB connectivity was then used to test SDRAM access and everything went fine too
Remaining is to share power supply between MAX 10 Board for SIM and this board, to solder the connectors between theses two boards and hope both work well together. Theses connectors are kept unsoldered until the last moment because the ones I'm using are no longer manufactured so that would like to reduce their loss because of broken board.

Christmas tree ornament which passes memory test too. Video available here to appreciate the LEDs blinking.

2019/10/08 : SIM stops working when connected to MAX 10 Board ?! After many head scratching and worrying about what's wrong, I could identify the pin causing problem and bending it made possible to get both boards working together !
"Something" could be read from Wasca FPGA via SIM , but read data seems corrupted : expected data to be read is lorem ipsum, but it is sometimes read correctly, sometimes as garbage.

Lorem ipsum read test (Click on the image to see it animated)

2019/10/11 : After tuning a bit the timings on SIM side, data from Wasca FPGA could be accessed ! Writing a 1 MB file on Wasca's RAM and then reading it back shows that data is still corrupted here and there but that's more or less like when I tried on real hardware, so everything is fine
It was a good idea to design this simple Rev 0.7 (b) board and to start assembly with this one rather than Rev 0.7 (a), because it allowed to test both SIM and Wasca FPGAs separately, which would had be difficult on Rev 0.7 (a) because both are set on the same board. It cost me three weeks and around 50$ additionally to Rev 0.7 (a) PCB, but this was time and money well spent !

Wasca test registers correctly read back from SIM

2019/10/12 : The box to protect this board is ready. As it is just for personal use and because I didn't wanted to waste too much time on it, it's a bit botched but not bad for a first try.
For the record how botched it is, I used an unpopulated PCB to get a rough idea where to drill holes for LEDs and switches ... and drilled both the PCB and the box under it (sorry) because I didn't wanted to waste time to mark where to drill on the box
I don't have a lot of regrets to have did that because that's better than not using the PCB : I ordered 10 pieces of this MAx 10 Board Rev 0.7 (b) PCB (because ordering at smaller quantity doesn't really changes the price), so that's basically 9 spare boards ... or let's rather say 8 spare boards now because the second used one is now full of holes

Up : MAX 10 Board for SIM, re-used for this project Down : MAX 10 Board Rev 0.7 (b) itself.

The boards assembled and put in case. (case top cover not visible on this picture)

View from bottom side, with SIM's MAX 10 Board and its JTAG extender visible

USB dev cart - Rev 4.2 (a) PCB Design : March 2020

I hesitated a bit in naming this board "Gamer's Cartridge" or "USB dev cart" because it gathers both on a single PCB. But since I don't plan to make this board publicly available, I used "USB dev cart" project name because I officially discontinued it.
Concept of this PCB is not only to gather Gamer's Cartridge and USB dev cart on a same board because I already did that a long ago Main challenge is to develop a "Gamer's Cartridge on steroids" as described below :

- Backup memory cartridge emulation as done with Gamer's Cartridge
- USB transfer with PC as done with USB dev cart
- PCB shape compatible with Action Replay shell
- Up to 8MB expansion RAM

Except the fact of using a physically larger CPLD than the one used in Gamer's Cartridge, merging Gamer's Cartridge and USB dev cart on a single PCB was quite straightforward. This was the occasion to inspire from the cursed Rev 2c board to place and route flash ROM chips
Biggest challenge is to add 8MB expansion RAM support : that's not "8Mb", but "8MB", which is twice more than required to play games requiring 1MB/4MB RAM expansion ! Main reason for that is to add support for Heart of Darkness, which is the (only ?) known game requiring more RAM than usual. Also, this was designed to provide up to 8MB RAM ... because there was enough free room on the PCB to do that

RAM used in this cartridge is SRAM, which is simpler to interface than SDRAM used in Wasca, but also horribly expensive. For this reason, this is not intended to be a public project but rather to be a "proof of concept" of providing cartridge expansion RAM. For me, that would be used as a reference to fix expansion RAM feature on Wasca, and it would also be the occasion to finally play Heart of Darkness on real hardware too

... Unfortunately I couldn't get that expansion RAM working I guess that it is caused by a problem regarding (partial) support of 5V voltage logic by the SRAM chips I selected. Initially, their datasheet was announcing a complete compatibility for both 5V and 3.3V logics, so I went ahead in designing this board. However, I discovered an application note stating that it's both 5V and 3.3V compatible under some conditions () during the last verifications when finalizing the cartridge. Since that application note was a bit ambiguous and that the cartridge was almost finished at that time, I ordered the manufacturing anyway, gave a try ... and verified that it was bad luck for this time

I started Wasca project in 2016 and am still doing it right now in 2020, so I don't surrender easily Let's hope it will be a success in next iteration
Apart from that expansion RAM failure, it is (finally !) a cartridge gathering both USB dev cart and Gamer's Cartridge and fitting into an Action Replay shell ! This will surely be useful in the future

USB dev cart "Rev 4.2 (a)", with SRAM not recognized

MAX 10 Board - Rev 0.7 (c)PCB Design : March 2020

^{Description of this board praises a bit Terasic products, but I'm not sponsored nor receiving any kind of external support by them or any third party entity ! There are many other development boards available from several makers, so please consider the pros and cons from a wide point of view if you want to select a board fitting the needs of your own project}

I stopped manufacturing Gamer's Cartridge at the end of 2019 to get more time in developing of other projects. One of the effects of that was the development of MAX 10 board Rev 0.7 (b) getting mature enough to put me in mood of continuing this project and by extension, Wasca too.
But, MAX 10 board Rev 0.7 (b) was just a "simple" board that I quickly developed just in the purpose of testing how well (or bad) a Wasca-ish interface of A-Bus and SIM would communicate together. Except that, all other features such as STM32 microcontroller support were discarded to shorten the design time of this board.
A natural evolution of the project would had be to move on MAX 10 board Rev 0.7 (a), because it was designed specifically for that purpose of featuring everything on a single board. But because it requires to solder a lot of components on the same PCB, the risk of a failure was high ... In fact, I was keeping MAX 10 board Rev 0.7 (b) simple for that particular reason to avoid of being stuck in electronical debug, and I didn't wanted to fall in this trap just after that

By chance, Mr Santa (a family member, not a sponsor !) had a $100 budget for me at the end of 2019 So after many hesitations I choose a DE10-lite board because with its MAX 10 FPGA and SDRAM memory chip, it is very similar to the architecture of Wasca and MAX 10 boards.

By using this DE10-lite board, I only had to design a daughter board with data/address multiplexing, SIM and STM32 interfacing to be able to get an equivalent of all boards developed so far. Apart from gathering everything in a single board, it is also very less risky than trying to design and assemble everything by myself
Additionally, as DE10-lite board provides way more resources than Wasca needs, worrying about limitations caused by hardware shouldn't be a problem now :

- Upper spec 10M50SA FPGA : that thing taken separately is more expensive than whole DE10-lite board That's clearly not the kind of logic device I would buy just for fun ... and it would be completely useless because I don't have the toolings to solder BGA chips
- 64MB SDRAM, which is twice the capacity used in Wasca. Wasca doesn't uses that for the good reason it costs around 4 times more than a 32MB SDRAM chip
- On-board USB Blaster (used to program the FPGA), which saves the price of a Terasic Blaster = $50
- A bunch of switches, LEDs, and even some 7-segment displays

More than raw specs themselves, I also wanted that new MAX 10 Board to be at a reasonable size, for example fitting in the kind of 3.5" HDD case used in MAX 10 Board. So I took enough time to consider about proper board shape and dimensions that would fit that requirement

Also, I wanted to reduce the number of cables required to use this board, because so far everything was an horrible spaghetti mess !

- Power supply was requiring its own USB wire and an external battery, but now merged with USB blaster
- USB blaster was so far sold separately ©, but now integrated in DE10-lite board
- Communication with the FPGAs of DE10-lite and SIM would initially require their own USB port, but it was limited in a single one communicating with SIM, which would redirect communication to DE10-lite if requested

That integration of USB Blaster is a good thing that made me deciding to pick a Terasic board, because other concurrent makers require blaster to be separately provided and connected, which is a pity for a development board whose main purpose is to be connected with development PC ! Back in Summer 2019, at some moment of the early design of MAX 10 board Rev 0.7 (a), I though about making layout of the board being capable of handling the PCB of a Terasic blaster, but I gave up because it's bulky and a bit expensive too.

"Warping" the communication to DE10-lite via SIM required several changes on MAX 10 firmware as well on PC software side, which I initially thought would not require too much effort to implement. But because except this communication with PC, the remaining way to do some debugging on DE10-lite board is to use LEDs and 7-segment displays ... and as I like to do a lot careless mistakes during such kind of critical development, things were a bit harder than expected
But after enough effort, SIM is now able to handle communication with DE10-lite ! As expected, communication performances are poor, but that's one USB serial communication to hold them all, which is quite convenient
(And this was the occasion to add a Knight Rider effect on the dots of those 7-segment display, which is priceless !)

At last, this board features two SD card socket : initially, it was only planned to connect SD card to STM32 microcontroller, but as there was some space remaining on the board, I took the occasion to add another micro SD socket for direct usage from DE10-lite board.
Wasca architecture will certainly end into a MAX 10 FPGA for interfacing with Saturn A-Bus, and a STM32 microcontroller to handle connectivity with modern media such as SD card. But it's not impossible it would also be forked into a feature-limited model with only one MAX 10 FPGA doing everything, so that I'm preparing this PCB to be an "all-in-one" ©®^TM board supporting every development scenario that is likely to happen in the future !

---

MAX 10 Board 0.7 (c), 2020/02/08 Nearly everything placed and routed	MAX 10 Board 0.7 (c), 2020/03/16 Finished to polish the little details
MAX 10 Board 0.7 (c), 2020/03/16 Just before sending to PCB manufacturer and rendered in "raytracing" mode

---

Hardware / Firmware / Software Development Log
2020/03/16 : Ordered manufacturing of the board, simultaneously with USB dev cart Rev 4.2 (a).
2020/03/26 : Shipping and import taxes cost respectively an arm and a leg, but PCBs were received without any major problem !
2020/03/27 : Soldered the chips requiring usage of flux.

MAX 10 Board 0.7 (c), 2020/03/27 Only chips requiring flux are soldered.

2020/03/29 : Soldered some small compoments so that only connectors are remaining to (hopefully) get MAX 10 working. In the meanwhile, it's now the right time to prepare a firmware for this board !
Also, I had to cut a bit the PCB to be able to connect with DE10-lite board. As I don't have a saw to do that, I used a drill and a nipper, and it was the moment for me to realize that even if tightly drilled, a PCB is still stronger than an "precision" (understand : "weak") nipper ... now I got two halves of that "precision" nipper

MAX 10 Board 0.7 (c), 2020/03/29 Almost ready to receive a firmware !

2020/04/05 : Finished to solder the connectors for DE10-lite board, and finally could get some positive results in communicating with it !
It was a bit exhausting but seeing all those LEDs and numbers blinking were worth the hassle

MAX 10 Board 0.7 (c), 2020/04/05 Communicating with DE10-lite ! Video of the Knight Rider effect available here.

2020/04/12 : DE10-lite can now communicate with STM32 ! Everything is similar to what was done in MAX 10 Board, including the known bugs I neglected to fix so far
2020/05/17 : Box to protect MAX 10 Board, DE10-lite and STM32 boards is finally ready !
PCB was designed a bit too optimistically (not to say "lazily" ) regarding mechanical consideration, but everything is firmly held and the box is protecting from external shocks, which is the most important
If in the future I need to build a similar MAX 10 Board I shall certainly catch the occasion to add some mechanical tweaks here and there to make next iteration of the PCB even better !

MAX 10 Board 0.7 (c), 2020/05/17 All three PCBs together, front side	MAX 10 Board 0.7 (c), 2020/05/17 All three PCBs together, rear side
MAX 10 Board 0.7 (c), 2020/05/17, side view Top : MAX 10 Board itself, foreground : DE10-lite, background : STM32 board
MAX 10 Board 0.7 (c), 2020/05/17 Box, front side	MAX 10 Board 0.7 (c), 2020/05/17 Box, rear side

To be honest, I think too that the box is as ugly as a lollipop that dropped on the carpet, but it took an eternity of my scarce free time to prepare it and that's probably the best I can do too. So maybe it's the time to switch on other parts of the project.

The last thing remaining on hardware side is to solder the SD card socket for STM32 microcontroller, and maybe to solder an extra couple of switches and LEDs too. I have only few SD card socket in stock and it is used in Gamer's Cartridge, so it is smarter to solder it when firmware development on STM32 side will be mature enough to get the guarantee that I didn't messed anything on hardware side

BTW, firmware development status didn't moved from previous month ... next bugfix I should challenge now is around log messages communication between MAX 10 and STM32 : when it will be reliable, it will finally be ready for other features requiring communication between MAX 10 and STM32, such as access to SD card
2020/05/22 : Log messages are finally sent correctly from STM32 to PC via MAX 10 !
I initially thought the problem was caused by a weird behavior around asynchronous communication beween MAX 10 and STM32, but everything was fine there and instead the problem was "just" caused by a group of small (but nasty) coding bugs.
After a moment of trying to test every changes on the MAX 10 Board, I get bored and made a small test bench (for PC) to reproduce and diagnose the problems more easily which helped a lot in fixing that ... so, yes, this problem waited this new MAX 10 Board for more than 6 months for being investigated, to then realize that it could be solved mostly by only using PC
2020/09/07 : After (another) hyatus, I'm slowly progressing in firmware development Next step is to make STM32 being able to access SD card
STM32 gladly provides a simple way to add SD card low level access (SDIO) and file system library (FatFs), which are cool when they work straight out of the box, but a pain to debug when a problem happens. And of course a problem happened
When using SDIO, only SD card registers (which contain SD card capacity, serial number etc) could be accessed, but data sectors were always empty, hence making FatFs to fail in detecting a file system. So after verifying possible culprits (SD card power supply ? wrong pull-up resistors ? Bad software configuration ? Misuse of a magic spell ?) and not finding anything relevant I started to slowly give up ...
But before postponing that task to next decade, I quickly made another SD card socket to connect on a spare STM32 board as a B-plan in the hope of isolating the problem and fixing it thanks to rapid prototyping. And of course nothing went well, because the SD card was then not even returning any register at that time ! And a bonus, I botched one finger when trying to connect a wire to a 0.1" pin header

So after unsurprisingly realizing that my hardware prototyping and debugging skills are nothing, I started C-plan of doing bitbang on SD card pins without the use of modules provided by STM32 development environment. This have the disadvantage of slowing down the access to SD card, but that's better than no access at all And this have the big advantage of using a codebase I'm quite used to mess with, because Gamer's Cartridge uses bitbang too !
Thanks to re-using code from Gamer's Cartridge and directly accessing SD card pins, I was almost sure that everything would be OK on software side, and ready to add the right debug artifact at the right place in the case a problem would happen. Of course, a problem happened : SD card DOUT pin was always returning zero to STM32, which after a brief investigation was caused by STM32 pin connected to ... ground pin instead of correct pin on SD card socket

It's not I want to brag, but I noticed about this problem by myself ... but it took me something like two weeks to finally notice this beginner mistake

After correctly tying-up this DOUT pin with STM32 input pin, things worked well better, with read speed around 290~350 KB/s, which is not bad for a raw access not using any hardware acceleration
Next step is then to use back SDIO access, first at 1 bit access width, and then (the fastest) 4 bits access width and see how well read performance is improved ... but before that I should sleep a bit
2020/09/08 : 9200 KB/s when reading a file from SD card with SDIO 4 bits access ! It's cool when things are working well