Category Archives: Hardware

OneChipMSX Mouse support

Posted on by
3

I’ve been intrigued by SymbOS for a while, and being able to play with it was the main reason I wanted to try and port the CPCTrex core to a more current FPGA platform at some point (a task that will be tackled sometime between “one of these days” and “the heat death of the universe”, mainly because of the need for some kind of CompactFlash-to-SD bridge component.)  However, SymbOS runs on MSX as well (and could in theory be ported to anything Z80-based provided it has enough RAM), so now I have the OneChipMSX core at my fingertips, I can finally give SymbOS a whirl.

There was just one thing missing – a mouse!

Continue reading →

Wiring up the Sega/CD32 adapter

Posted on by
Reply

A few weeks ago I pushed the PSoC Creator project for my Sega-6-button-to-CD32 converter project, but anyone wishing to build a converter would need to know the pin mapping.  This is defined within the Creator project, but figuring out which pins on the DB9s need to be wired to which terminals on the board would be pretty tedious – so here’s a wiring diagram for the benefit of anyone who wants to have a go.

(Please note, the board shown here is the CY8CKIT-049-42XX – the identical-looking 41XX won’t work because the chip lacks the programmable logic the project uses to create the shift register.)
Wiring

How many angels…

Posted on by
1

… can dance on the head of a pin?

I have no idea – but I do know how many ZPUFlex processors will fit in a DE1 dev board: 25!  [Edit: I’ve since managed to squeeze in another one – so 26!]

OK, I’m stretching things a little to claim that 25 fully-featured ZPUFlex CPUs will fit on the DE1, because these have a really tiny ROM and very minimal supporting logic, so Quartus can optimise the hell out of the design – but it still seemed like a fun demo.

Source, as always, can be found on GitHub.

[EDIT: The M4K memory blocks on the DE1’s Cyclone II support 32-bit data width, but not in full dual-port mode, where the data width is limited to 16-bit.  This means that no matter how small the ZPU’s ROM/StackRAM, it will occupy a minimum of 2 M4Ks.  If it weren’t for this fact, I think the DE1 could take 3 further ZPUs.  As it is, it’s possible to add just one more instance of the ZPU, and the code on github now reflects this.  The record for the maxmium number of soft CPUs in a single project on the DE1 board is now 26.  Unless you know diffferent!]

Hello World in 546 Logic Elements!

Posted on by
4

I wrote once before about the HelloWorld example in my ZPUDemos repository.  This demo used the ZPU processor and a minimal UART to send the archetypal “Hello World!” message to the serial port, and used just 684 logic elements to do so.

I’ve revisited the project, and added a new demo to ZPUDemos, which shows how the ZPU’s size can be reduced even further.

By bringing a copy of the zpu_config.vhd file into the local project directory and modifying some of the constants within we can reduce the size of the CPU’s internal address registers.  This saves quite some logic, since any unused address bits can’t be automatically optimised out, thanks to the fact that addresses can be written to and from the Stack RAM.

Since the HelloWorld ROM is between 1 and 2kb in size we need to use 11 address bits (10 downto 0), and allow one extra bit to produce some IO space, so we set maxAddrBitIncIO to 11.  Since we’re using the de-facto ZPU convention of allowing the MSB to designate IO space, then any operations that don’t involve IO can use a max bit of 10 – thus we leave maxAddrBit set to maxAddrBitIncIO-1.

This change brings the size of the ZPU itself from 549 to 462 logic elements.  This combined with adjusting the peripheral code to deal with the narrower address space, and disabling the UART RX brings the entire HelloWorld project from 692 logic elements (there have been tweaks and bug fixes since the previous result of 684 was achieved) down to 546!

Besides logic area, there is another benefit to trimming unused address logic: simplifying the logic – especially of the 32-bit adder which increments the program counter – relaxes the CPU’s timing requirements somewhat, and there’s a noticeable improvement in fmax as the address space narrows.

Reading a Sega 6-button pad

Posted on by
Reply

Part 4: Up and running

I’m pleased to report that the first prototype of the PSOC4-based Sega 6-button pad to Amiga CD32 adapter is now up and running.  In the process I’ve learned a lot about the PSOC4 platform, and I have to say as a development platform I really like it – I have no doubt I shall be using these devices in future projects.

PSOC Creator Project files for the adapter can be found at https://github.com/robinsonb5/SegaToCD32

Reading a Sega 6-button pad

Posted on by
Reply

Part 2: some code

In my earlier post I mentioned that I was going to handle reading the Sega 6-button joypad in software, using an interrupt routine, and use programmable logic to handle masquerading as a CD32 pad.

The six inputs from the Sega pad (up, down, left, right, button1, button2) are mapped to PSOC pins P2.0 to P2.5.  Since these are adjacent, we can read and write to them easily as a single entity.  We create a “pins” component with six inputs, named Sega_Inputs, and PSOC creator automatically generate headers and stubs so that we can read their status in main.c simply by calling Sega_Inputs_Read().  Similarly, we create an output pin, Sega_Select on pin P2.6, which we can write in the code using Sega_Select_Write().

Continue reading →

Reading a Sega 6-button pad

Posted on by
Reply

Part 1: The Plan

One of the projects I have in mind for the PSOC4 chip on the CY8CKIT-049-42xx boards I picked up recently is an adapter to allow 6-button Sega Megadrive controllers to be used on the Amiga.  I already made such a device a couple of years ago using a PIC microcontroller but never finished the project (I discovered FPGAs round about then!) and the programmable digital blocks in the PSOC4 make it an ideal platform for resurrecting the project.

Initially I shall read the Sega pad in software, using an interrupt routine, then implement the CD32-pad shift register using the programmable hardware in the PSOC4.

The original Sega Megadrive gamepad had four buttons: A, B, C and Start.  The pad used a standard Atari-style 9-pin DSUB connector, and while the four directions and button B were mapped using standard Atari wiring (pins 1,2,3,4,6), button C appeared on pin 9.  Most Atari-like gameport connectors have +5v available on pin 7, but the Sega variant has +5v on pin 5.  Instead, pin 7 is used as a select signal, which multiplexes the pins normally occupied by the B and C buttons.  When the select signal is high, B & C are readable, and when the select signal is low, the status of buttons A and Start appear on those lines instead.

When it came to adding extra buttons to the six button pad, Sega needed to find a way of multiplexing extra buttons in such a way that they didn’t cause compatibility issues.  The obvious solution of making extra buttons replace the direction lines when the select signal is low wasn’t possible because the existing 3-button protocol already held the left and right lines low when select was low, presumably so software could distinguish the 3-button pad from a standard Atari-style joystick or Master System controller.  Instead they went with a “magic knock” approach, in which software toggles the select line four times in quick succession.  The new buttons appear on the directions during the high pulse following the third low pulse, and to identify the pad as a six button button, the direction lines are low and high for the low pulses before and after this, respectively.

SegaPad