Imperium Solo – SEGA MD/Genesis

Imperium Solo USB is an adapter to support modern day USB game controllers (&mice) on retro hardware.
Today I am happy to announce that I added support for the great SEGA MegaDrive/Genesis console.
It was not all trivial, due to the SEGA 6 button mode, which is now fully supported by Imperium Solo USB, granted you have enough buttons on your controller, check the database at the Imperium Solo infosite.

Furthermore SEGA choose to use VCC on another pin than the “atari-standard”, thus existing Imperium Solo PCB’s are not able to support it. However it was added as configuration option in PCB rev. 1.0.4.
External power can also be applied via a USB micro socket (standard mobile phone charger would work), if extra power is needed. Options are configurable via jumpers.

Here’s a short video demonstration:

Notice that I made a seperate site for Imperium Solo, here:

Where you can see the database of tested Game controllers and mice, along with their button mapping.

M4 Board – Guides/Setup/Help!

As have been drawn to my attention, many M4 board owners are asking for easier documentation than my crude instructions here.

Fortunately several great people have created helpful guides, reviews and documentation already. A huge THANK YOU guys!

First a series of excellent articles in Spanish from AUAmstrad website/group:
https://auamstrad.es/hardware/m4-board-configuracion/
https://auamstrad.es/hardware/m4-board-gestores/
https://auamstrad.es/hardware/m4-board-hack-menu/
https://auamstrad.es/hardware/m4-board/

Videos:
In Greek by Vincent GR:


Review by Chinnyvision in English:


In English from Jungsis corner:


Review and early setup by Am Strad in English:


And a guide in Spanish by Professor Retroman, that I linked to before:



Also Mr. DVG over at the cpcwiki forums compiled a collection of 1300 games tested and working with M4 board!

If I forgot or missed a useful resource, please do not hesitate to make a comment, so I can add it to this post.

Thanks again, all of you for your dedication, hard work and support!

Imperium Solo – Amiga & Atari ST

Finally got around to writing the firmware changes needed to support Amiga and Atari ST via the Imperium Solo USB adapter.

Here’s a video of Amiga version:

Atari ST video:

When I release the firmware updates, you can re-program the existing Imperium Solo C64 hardware with them, but not the Imperium Solo Amstrad CPC, as there is jumper settings via 0 ohm smd resisters that needs to be changed to be used on other hardware than the Amstrad CPC.

Notice that I made a seperate site for Imperium Solo, here:

Where you can see the database of tested Game controllers and mice, along with their button mapping.

Imperium Solo – C64

Small update on the Imperium Solo project initially released for the Amstrad CPC.
Made some changes to the firmware and changed two 0 ohm SMD resistor settings to support Commodore 64 and probably many other retro computers with my modern USB controllers to joystick adapter.

For now I used an external 5V powersupply, as you can only draw a limited amount of current over the C64 joystick port* and power usage will depend on the controllers plugged into the adapter (the adapter itself uses very little).
Will see first if there is interest at all for this adapter (maybe something similar already exist?).
Anyway here is a video of the C64 prelimary version.


*It turns out the 100mA limit per Joystick port (200mA total), is a limit of what the stock powersupply can deliver safely while keeping the system stable. Otherwise the 5V on the joystick port is directly connected to the PSU input with a nice fat trace. So if using a better powersupply or the devices connected to the joystick port use less than 200 mA current, there is no need for external powersupply.

About mouse support.
It is just joystick mode (1350). I cannot support the analog mouse mode (1351) with current PCB layout atleast.

Imperium Solo – Amstrad

Imperium Solo is a USB to joystick adapter, intended for using USB gamepads, like DualShock 3/4, XBOX One controller on retro computers.
It’s also possible to use USB mouse.
For now the project only supports the Amstrad CPC range of computers, but I plan to make firmware updates for use with other retro computers.

The firmware is updatable by pluggin in an USB stick/drive (FAT32) with the correct file when the adapter is powered on.

Special supported controllers are only DualShock 3, DualShock 4, XBox One controller and SNES USB controller.
Other USB HID controllers should work by using my generic HID parser, but controller mapping may not be ideal for those.
So I hope to add more controllers with the help of feedback from users.

USB Mouse is also using my generic HID parser, which atleast works with the 5 different USB mice I had laying around.
At a point I made a custom mouse mode, with 5 bit resolution for delta values making it possible to get much better mouse feeling(proportional mode).
This may be implemented to a later firmware update, if there is demand (it will need adapted software to be usable).

Made as compact as possible!

Below you can see a video of :

  • Installation/Connecting (notice most other retro computeres have power on the joystick port, so will not need DC splitter cable like the Amstrad is using)
  • Playing a game with USB controller
  • Playing a game with USB mouse
  • Playing a game with TWO usb controllers

Will update later with documentation (controller mapping, firmware upgrade etc).

Lastly expect another update, when I add firmware for the next retro computer.

M4 Board still alive and kicking

The M4 board for the Amstrad CPC computer series has now surpassed more than 600 shipped units. And I expect to pass 700 units this year, if things continue as now.

Though there hasn’t been any recent updates on this blog for the M4 board, I have released some firmware updates adding new features.

The biggest update came last year, when I added Hack Menu which is NMI triggering with ROM/RAM remapping.
Making it possible to have “Multiface 2” like features.

For existing users it can be launched via the web-interface or by manually soldering a switch onto the board.

As can be seen on the video above, it is now possible to save game progress and re-load it again, using the popular .SNA format, which is compatible with many emulators aswell.

However it is still in beta so it can crash under some circumstances.
I expect to do some major software improvement to this Hack menu.

How to add the Hack button to existing PCB’s.

Adding Hack menu button


Meanwhile I updated the PCB once again to have this new Hack button.

Hack menu button added to PCB (left – middle)

The PCB now being version 2.5C.

M7 Board

So what about M7 / Galaxy Board / Zen80 board ?
It’s not cancelled, but I haven’t really worked on it for a long while, I do have some overall changes in mind and hope to pick it up again.

Imperium Solo – USB joypads

I also made a USB to joystick adapter called Imperium Solo, which is also partial functionality of the Galaxy board. Its intended use is to be able to connect USB joypads and mouses to the joystick port. For now it supports CPC, but later it’s meant to be working with ZX Spectrum +2/+3, C64, Atari ST and Amiga. Or well lets wait and see 😉

Video showing the use of Dualshock 3/4 controllers on an Amstrad CPC!

I will update more on this soon, as I am awaiting the final PCB.

Greetings,

Duke

M7 / Galaxy Board

Another board I started a long time ago, but due to time/life, has been on the shelf.

M7 board is connected between a Z80 and it’s dil socket.
For starters aimed at the Amstrad GX4000 console (and of course the other Amstrads), boosting it to be a full blown CPC+ computer. But maybe later other Z80 based computers.
It gives similar features of M4 board ie.:
WiFi abilities
SD card as mass storage
Rom board
Cartridge emulation
and much more.

However due to the design it will be able to offer more than the M4 board.
The Z80 datalines can be intercepted, so technically any hardware can be emulated on the Cortex M7 chip (disc drives, tapes, keyboard), providing the Cortex-M7 can keep up.

The design is:
STM32F7 mcu handling the Z80 address, data and control lines, SD card.
STM32F1 mcu being USB host, interconnected to the Cortex-M7, via 8 datalines and 4 address lines (covering the keyboard matrix).
ESP8266 handling the WiFi, connected via SPI to the Cortex-M7
Level converter between Z80 datalines to STM32F7 with OE signal
And a bus switch to seperate the Z80 datalines from the motherboard, this way any response on an I/O port for example can be “replaced”.

Planned features for starters is, expanding ram, probably I will spare 256KB + the internal 64 KB for starters.
Add key+mouse option (via ie. logitech unified) through the USB socket.

 

 

 

 

 
Debugging signals on a CPC464 and physical layout.
 

 

Basics working on a Amstrad GX4000 console.

More to come when time allows.

M4 Board – Amstrad CPC WiFi, recap 2016

The interest for this project turned out to exceed anything I ever imagined and lots of units have been produced.

 

 

 

 

 

Showing some of the batches that was made, in my “garage” production.

The firmware was vastly improved, since the initial version.


Some key points:

  • Romboard was extended to 32 roms & ability to remap lowerrom
  • Autoexec.bas execution on start up
  • Long filename handling
  • NETAPI for native applications

Supporting the entire Amstrad CPC range from 464 to 6128 plus.

Firmware updates are available here:
http://www.cpcwiki.eu/index.php/M4_Board

And a link to latest beta firmware, documentation and development info can be found here:
http://www.spinpoint.org/cpc/m4info.txt

Software:
I released the source code of the z80 assembler part of the M4 DOS here:
https://github.com/M4Duke/m4rom

With this anyone can make their own custom build if desired and replace my build simply by copying M4ROM.BIN to the root of their sd card.

Other examples, handling the NETAPI from your applications:
https://github.com/M4Duke/M4examples

And of course the cpcxfer program, to conveniently transfer files between pc and the amstrad cpc over WiFi via commandline.
https://github.com/M4Duke/cpcxfer

Prodatron wrote support for M4 in his great SymbOS (http://www.symbos.de)
Giving you the ability to chat on IRC, download files via wget, copy files between floppies & sd and much much more.

Very impressive.

Look into this thread for download and installation details:
http://www.cpcwiki.eu/forum/applications/symbos-cpc-updates-and-infos/msg137192/#msg137192

A nice video for the CPC strong hold in Spain by Professor Retroman.

2017
There is still so much more that could be added in the future.

Keep an eye on this thread for future updates & info.
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-cpc-wifi/

Thanks all for your support.

Happy new year!

– Duke

M4 Board – Retrofun, 8-Bit Amstrad CPC WiFi

Description and purpose of the “M4 board”.
m4board_v2
The M4 board, features as previously described a ST32F407 Cortex M4 MCU, connected via SPI to a ESP8266 WIFI module, and 18 GPIO’s routed via a GTL2000 voltage translator chip.

It was meant to be connected to the old the Amstrad CPC (z80 based) computer via it’s expansion port.
As with most old age computers, it runs with 5V I/O, here is where the GTL2000 chip came in handy.
The signals driven through the GTL2000 are output signals and the bi-directional data bus (D0-D7).

Input signals are connected directly to the ST32F407 Cortex M4 as it is 5V tolerant.

The idea was to provide WiFi to the Amstrad CPC, for easy and fast data exchange between it and a PC, but also direct internet access.

ROM BOARD emulation
First prerequisite was the ability to run code on the Amstrad via the M4 MCU so no additional loading (i.e. disc) would be needed.
It would be done by mapping a ROM in the Amstrad addressable space, this ROM would be in the M4 ram.

IORQ and WR will occur when a ROM is selected, data lines will contain the ROM number.
ROMEN and RD will occur when a read is happening from the currently selected ROM, address lines have the address, ROM data will be send back over the data lines.
A fairly trivial task, but the timing is tight having to bit bang the gpio, do direction changes on gpio’s mapped as data lines, even when the bus runs at only 4MHz.
Much time spent optimizing the handler in ARM assembler, it finally worked.

SD card storage
Being able to run code via the ROM board emulation, it would be nice to have native r/w storage.
A micro SD card slot connected to the M4 SDIO lines, was meant for this purpose.
An transfer interface from the Amstrad CPC to the M4 was designed.
Two I/O ports were assigned when an IORQ happened, one for receiving data on the M4 and one for telling it data was send, so it could process.
This was done as it’s easy to store data (low clock count), but takes additional time to process them.
When the 2nd port is written, the MCU sends BUSRQ signal to the Z80 CPU, which will ‘freeze’ the z80 CPU at the end of the current cycle, now the M4 has the time it needs to process the incoming data, before resuming the Z80 CPU and responding.
Responses are done in the ROM space, which of course is read only on the CPC, but R/W on the M4, as it is kept in the M4 ram!
Next up, was to hook the system bios/firmware functions, that do file related I/O to tape and disc on the original system and re-directing them to the sdcard.
Thus native file access from the SD card is possible, providing the CPC with up to 32GB (or more) of storage via SD card.

WiFi & Internet
In short the connection between ESP8266 and the M4 was done via SPI as IPC.
To allow internet/WiFi access from the Amstrad CPC itself, it sends a command to the M4, which again sends an IPC call to the ESP.

WEB interface
The ESP8266 hosts a WEB server, where various settings can be altered.
web_interface1 web_interface2

RTC
A battery mount was put on the board, making it possible to provide Real time clock as well via the RTC in the ST32F407.

What it does
Emulate Romboard, currently up to 16 roms, can be uploaded/removed via Web Interface.
Download files from internet via WiFi.
Mass storage to SD card, via native file I/O. R/W support. Emulated as drive A.
Can use DSK files on the SD card too, but only for file read access and sector reading via firmware call.
Upload files via web interface.

See a short demonstration here:

To do
Finish commands.
Lots of error checking.
Bug fixing.
More commands.
Other features.
hooked_up_to_la
Should anyone be mad enough to want a similar interface for their Amstrad CPC (or other suggestions), don’t hesitate to put a comment.
If enough are interested, I will run a batch + it’ll motivate me to finish and polish things up.

-Duke

M4 Board – The SPI IPC

A little progress on the M4 Board, I managed to get the IPC (inter processor comms) system between the Cortex-M4 and the ESP8266 going.
It uses HSPI interface + GPIO0 on the ESP and SPI1 interface + a gpio on the M4.

SPI comms from ESP to Cortex-M4
Cortex-M4 acts as spi-slave, it will listen to the any incoming HSPI command from the ESP, via SPI_RXNE interrupt (on SPI1 irq handler, max. 42 MHz).
The irq handler is done with some very optimized assembler code and simply buffers whatever is send from the ESP, whenever there is something in the rx buffer. It also deals with sending any data if there is something in the transmit buffer to send.
HSPI CS will trigger an external interrupt on both edges on the M4.
When HSPI CS goes low, it will clear the index of the spi1 rx buffer.
When HSPI CS goes high, it will process the command/data received in the spi1 buffer.

Cortex-M4 to ESP
GPIO0 is set as input on the ESP and the M4 will pull this low whenever it wants to send command/data to the ESP. Prior to that command and data is written to the transmit buffer of the SPI IRQ handler.
This triggers an interrupt on the ESP, which will then start clocking dummy data out on the SPI to read/process the responses (full duplex).
This wont come in any faster than the ESP is driving the clock. The HSPI clock is set to 40 MHz.

Results
This system works pretty well now. It’s not as fast as I’d like. Currently transfer is about 500 KB/s, while I can download to the ESP with about 900KB/s under optimal conditions.
So the SPI IPC is a bottleneck, however there is still room for improvement.
As the clock speed is really fine on the SPI, the problem is the delay between each byte write from the ESP which is done via CPU writes.
Ideally I could use DMA, but there seems to be no info on this anywhere in regards to the ESP.
Another option is to use 16 bit read/writes instead of 8 bits and probably almost double the speed.
Or I could use the entire 64 byte buffer of the ESP HSPI interface and clock them out nicely without delays 64 bytes at a time.

Other
On the hardware side, I have re-designed the board and ordered new pcb’s. I screwed up the footprint of the GTL2000 chip and there simply was no way about. Obviously other improvements & fixes were added.

– Duke

spi_delaym4board_mess