Happy New Year!

Everblue wrote:

Then I ask the question.... Why does it only happen after that the board has been switched off for several hours?

My first guess would be a temperature induced issue, like the DRAM timing Wolfgang mentioned above.
After cold start of the board the issue is seen - while components on the PCB slowly heat up during operation, the timing paths shift inherently and move the whole design out of the failing corridor. That's annoying for debugging since the failure vanishes over time and you'd have to force the required thermal conditions to study the problem (with cooling spray or a fridge roll).

Another option could be static charge that's collected over time and pushes nodes to a stable level that would float otherwise. Quite unlikely IMHO but there's a quick check: Touching leads and terminals on the PCB charges / discharges them in case they're floating. You would see an impact on the failure - either the dots go away immediately or they persist even on a "hot" board.
Ground yourself beforehand, eg touch the metal housings of the connectors.


(6 replies, posted in Other platforms/cores)

ost wrote:

If you require buttons in addition to joystick, I suggest you just pick some keys on the kbd and map them up.

Right, this should be the first approach to work around the controller issue.


(6 replies, posted in Other platforms/cores)

Control (incl. keyboard) is still work in progress. The core requires 4 buttons, and I was looking into ways to hook up controllers to the Replay in this thread.
It's kind of stuck since there's no clean solution yet how to safely use the AUX IO pins for anything reliable.

Don't select any "Aux Controller" in the OSD other than "Joystick", otherwise you might break some ports on your Replay. That was the reason why I didn't commit a binary yet.

I like the idea of stamping the images.

MikeJ wrote:

And they occasionally change it.

Is it documented by Xilinx so the ARM code can handle different header revs? Devs would need to use "compatible" tool versions to support this feature.

We could avoid such a dependency if the info is embedded in the design and ARM reads it via SPI. Would be more complex though: a VHDL design gets patched during every compile run with time stamp or SVN rev.


(30 replies, posted in Other platforms/cores)

wsoltys wrote:

*humpf* was a problem with the framework.

Glad to hear that smile

Amazing collection of ports in your repository btw cool


(30 replies, posted in Other platforms/cores)

I also checked some more of Daniel's games: Bejeweled, BUSTin Out V3, Dacman, Ghostblaster, Happy Halloween... All working fine with the current Replay port. At least title screen and some gameplay.

Since to fpga_colecovision_2.1.tar.gz there were some few changes, but none of which I'd call significant. Mainly extensions for integration into the Replay framework. Hard to say why the pace port exhibits these issues.


(30 replies, posted in Other platforms/cores)

arnim wrote:

Had a quick look found that the ini file doesn't use Wolfgang's advanced flags for file upload yet.

Ok, the new ini file solves this issue. Games should immediately fire up now after downloading the cartridge via OSD.


(30 replies, posted in Other platforms/cores)

Hm, just speculating. The bin file was created E/Feb and I lost track of all the changes since then.

Had a quick look found that the ini file doesn't use Wolfgang's advanced flags for file upload yet. Guess that's worth a review tongue

No idea what's going on with the core's keyboard integration though.


(30 replies, posted in Other platforms/cores)

I tried this game and it appears to work with the Colecovision core in Replay SVN.

For some reason there seems to be a couple of regressions

  • Sometimes you need to perform "Reset Target" from OSD after loading the cartridge file. IIRC this was not needed a while ago.

  • Keyboard input is not working anymore.

Maybe both are related to the latest ARM/Replay lib updates, some investigation needed.

But as a summary, GhostBlaster can be played with a standard DB9 joystick in Port A. Just press the button to start.


(30 replies, posted in Other platforms/cores)

wsoltys wrote:

One learning piece is the fpga colecovision from pacedev which afaik is based on the fpgaarcade version. I've ported it to the MiST and it runs the original games pretty fine. But it freezes at the startscreen when running homebrew.

Sounds like the FPGA Colecovision which I developed for fpgaarcade.com years ago wink
The current port for the Replay is very much the same code base which I released back then. So well, if there's a game that doesn't work then please provide a link to the binary so I can check it and eventually update the code. As you pointed out, most (all?) commercial games work but the homebrewn stuff tends to make excessive use of undocumented features.


(15 replies, posted in Board support library)

Johey wrote:

When thinking about it, there is another one out there with similar properties - the Sega Megadrive pad. Also mostly compatible, though some button combinations can harm a C64 (I've heards at least... Never looked at the schematics).

The docs here and here show that we face a new fundamental issue with this type of controllers: Sega assigned the power supply to pin 5 whereas the Replay supplies at pin 7. Additionally, the select function is required at this pin 7 - you won't even be able to patch this on the Replay.
Therefore I don't see a chance to support the 6-button Megadrive pad with Replay's joystick ports. Even the compatibility mode has probably stability issues, though it shouldn't harm the board.


(15 replies, posted in Board support library)

Johey wrote:

Good job! I still think the CD32 interface would be the best reference design, as it is directly pluggable into the Replay, backwards compatible with Amiga/Commodore/Atari style, and has a lot of additional buttons.

CD32 seems to be the best fit, right. Unfortunately it doesn't work out of the box in full CD32 mode with the Replay. I had to apply two soldering patches to get it running at the DB9 connectors:

  • Move L17 to L16

  • Re-wire an AUX-IO pin from the spare locations to pin 6

The first one is required to properly supply the pad's internal logic with 5V. With the default 3V3 it might not work at all, even in compatibility mode. While the additional AUX-IO is needed to fully control the logic and talk to the pad.
Both patches are a bit tricky to perform since the respective solder pads are rather small. You'd need a decent solder tip and a steady hand neutral

Johey wrote:

When thinking about it, there is another one out there with similar properties - the Sega Megadrive pad. Also mostly compatible, though some button combinations can harm a C64 (I've heards at least... Never looked at the schematics).

Ah, good hint. Will dig into this as well.


(15 replies, posted in Board support library)

A quick status update:
Native gamepad drivers for CD32, Gamecube and SNES are functional. The Adventure Vision core is my current testbench since it requires a 4 button controller roll N64 will surely follow and if possible I'll look into PS2 support.
But before they can see broader use in other cores we'll need to sort out the best way how to connect them electrically to the Replay. This brought up more headaches than I expected initially.


(11 replies, posted in News)

Nice approach!

Just managed to install all required tools of the chain - I can compile the PDF now. Time to brush up my dusty LaTeX skills hmm
What level of details would you like to see in the manual? Guess everything we'd need to tell the user to get a core running. Implementation details as well? Replay lib component docs?

A 'clean' target in the Makefile would be handy wink

arnim wrote:
foft wrote:

#         31                             0,  31                             0

It's most likely the comma. The INI parser doesn't escape ',' in comments and seems to dissect the line into something weird.

Ah, I mixed it up. Had this problem with comma inside strings. Not for comments roll

foft wrote:

#         31                             0,  31                             0

It's most likely the comma. The INI parser doesn't escape ',' in comments and seems to dissect the line into something weird.


(15 replies, posted in Board support library)

Finally found a source for CD32 compatible joypads @ Vesalia.
Once thay ship I'll dig into a driver. From design point of view it'll be quite simple to implement the protocol, but electrical interfacing will require some tweaking though.

@Mike: The schematics tell me that the joystick ports are supplied from the 3V3 rail. Where's the mounting option L16 located on the board? I'll probably need to feed 5V to the joystick ports to get the LS-TTL logic inside the joypad alive. Would it be safe to feed the Spartan 3 INs from 5V logic? These 270R series resistors in the JOYA[] lines should do the job, right?


(15 replies, posted in Board support library)

Johey wrote:

I wouldn't mind support for more protocols though, but the CD32 would be a great start I think. smile

Yes, CD32 would perfectly fit in there as well. It's a serial protocol like many others I've seen so far.
Found this tech doc CD32Gamepad which explains all the details. Do you know other sources?


(15 replies, posted in Board support library)

Chrabster wrote:

PS2-CD32/Amiga/Commodore/Mouse adapter already exists...
http://www.youtube.com/watch?v=apd_H6gc … jX7xptO-gA

Unfortunately not much hardware related information in there.

I was banging my head against this for quite a while now: How to include support for modern game controllers?
Nothing against arcade-grade joysticks wired up in a cabinet setup. But often I'm missing the possibility to play games with something like a SNES gamepad, a Gamecube controller, or maybe PlayStation/XBOX controllers (yes, I took the Nintendo path wink). Don't know how you guys think about this, so I'd like to come up with a proposal here.

Imagine a component in the Replay library that integrates all the protocols. Let's say like drivers for each of the supported controllers. The core gets a whole bunch of information about controller status. Buttons, digital pads, analog info from sticks & shoulder buttons - in any forms and numbers. It would be the same for each core since the library component is shared, nice to integrate and each core would come with the same set of supported controllers.
On the user side, an OSD entry allows the user to select which controller is actually attached. The respective driver is fired up internally and your favorite controller starts talking to the core.

Some tech ref
Gamecube Controller
PlayStation 2 Controller
CD32 Controller
SNES Controller
N64 Controller
SEGA Mega Drive and segasix.txt

Looking at the lower levels, we'd need an attachment to the controllers and a VHDL interface to the cores.

Physical Interface
The existing DB9 joystick ports could come in handy here. They have 6 inputs, 1 in/out, and on top a power supply. 7 lines seems a lot but 1 IO onle is not enough for talking most controller protocols. Some would work with 3v3 supply, older parts require full 5v0. Let's see.
Once a driver is active, it has full control over all 7 IOs with respect to input, output, and output driver enable. Most controllers would need a pull-up resistor here and there - these would need to go into the adapter cable. Right, the adapters will be very specific to mate with the controller. You could think of ripping apart an extension cable and solder a DB9 connector to the other end.

You might be even able to hook two controllers to one DB9 port, ending up in probably max 4 controllers with this approach.

VHDL Interface
Not thrilling at all:

  • Clock

  • Reset

  • Time reference (VHDL generic to specify the MHz?)

  • Driver selection (it could serve different types in parallel)

  • JoyA, JoyB port connections

  • Controller status output:

    • Buttons 1-n (could be further grouped)

    • Control buttons like Start, Select

    • Shoulder buttons (or included in overall button list?)

    • Digital X/Y (more than 1 set if controller has multiple sticks)

    • Analog X/Y (again, more than 1 set)

    • Analog slider/button

All that could be thrown into a new entity, say Replay_GameControllers. I'm not sure whether Replay_JoyPS2 would be the better place for it.

Now, these are my initial ideas on this topic - what do you think? Many of my old designs were linked to SNES and GC controllers, so nice big_smile Once a basic concept is settled, I could introduce an initial sketch in the Replay lib for further extension.


(92 replies, posted in C64)

Artlace wrote:

I know it's a bit of stretch but would it be possible to put your core in a small FPGA on a PCB and use it as a SID replacement?

I wonder if it would fit into an FDIL V2 wink


(6 replies, posted in Other platforms/cores)

The Replay port is progressing. Most work goes into housekeeping stuff for the Replay.

I discovered the Code Red Demo that squeezes mind boggling stuff out of this system. It's quite challenging for the spinning-mirror-and-LEDs monitor that needs to be modeled for a CRT/TFT like display on the Replay.


(30 replies, posted in Other platforms/cores)

Johey wrote:

If possible I think the CD32 controller should be supported in the Replay lib.

I'm keeping an eye on how the Replay lib evolves regarding enhanced joystick support. So at least any upgrades here will find their way into this core. That's why I was reluctant to implement any one-of-a-kind solution for this core up to now.


(30 replies, posted in Other platforms/cores)

Johey wrote:

Is this implementation accurate?

It aims to be accurate. However some topics remain for further improvement.

For simplicity of design a reduced color palette is used at the moment. It's the "MF & MdK" Variant from Richard's article. It would be no principle problem to switch to the "real" palette, but this would require some significant tweaking of the data path in Replay_VideoConverter. Otherwise the internal memory resources would simply overflow. They're already pretty exhausted at the moment since all memory is internal (BIOS, VRAM, cartridge).

From the functional aspect probably a couple of open items reside in the VDP. I implemented it according to the datasheet. Apart from this intended functionality, there are a lot of undocumented features and even display modes that are side effects of the specific TMS9918 design implementation. I considered only a subset of what is common knowledge in the homebrew community. Will add more over time.

Finally, I didn't test each and every Colecovision title out there. Especially when it comes to homebrew software.

Baseline: Pretty accurate for (most) commercial games. The Colecovision afficionado will miss things here and there wink