carmiker

There is no binary build for anything other than Windows (and a port to OpenEmu for macOS), but it is very easy to build for Linux running on any architecture. Instructions to build are here (you can use a static build like this Windows build, or use the generic frontend and use the emulator as a module): https://gitlab.com/jgemu/jgrf https://gitlab.com/jgemu/jollycv

This is a great idea. The reason the situation is the way it is right now is that I created a generic frontend for all of my emulators and ports, originally with the intention of only having emulators exist as modules or "plugins", but later decided it would be good to be able to link the frontend to any emulator to create standalone executables. The README for the generic frontend contains all of that information, but it would certainly be better for static builds to have some basic information contained within a "Help" menu. What you're using is the JollyCV core linked to "The Jolly Good Reference Frontend". One day I hope to make something more user-friendly and I will be able to link the emulator core to that as well. See: https://gitlab.com/jgemu/jgrf, https://jgemu.gitlab.io/ Thank you for the compliment. Originally, this codebase was meant to be an educational aid for university level computer science students, so I took great care in making the code readable and understandable for use in an educational environment. That didn't quite work out, but I still maintain this goal anyway :).

The emulator core itself is extremely portable, so it would not surprise me if this is possible, assuming there is an ISO C11 compliant compiler. I don't think DJGPP would work specifically, but maybe someone has created a toolchain for DOS that supports newer standards. It would also need a DOS-specific frontend, maybe using an old revision of Allegro or something.

Hello ColecoVision fans, I have finally gotten around to building a standalone Windows binary of JollyCV. I started writing this back in 2020, and it has now evolved to a mature state. All commercially released games should run, and the Roller, Steering Wheel, and Super Action Controller are all supported (though the Steering Wheel is sometimes a little dodgy). I should note that this was built and designed on Linux and is really still a "Linux program", so it is not the most user-friendly, and must be executed from the command line or have a ROM dragged to the executable. You need OpenGL 3.3 support, and you also need to supply your own "coleco.rom", which I know all of you have dumped on your own legally . Once it is running, TAB will bring up the menu. F1 and F2 will reset, F5/F6 save states, and F7/F8 load states. https://gitlab.com/jgemu/jollycv Enjoy. jollycv-1.0.1.zip

Let's add some screenshots. Pretty pictures are nice!

https://gitlab.com/jgemu/jollycv I have implemented Super Game Module emulation. It works well from what I can see! Next up will be support for the spinner interface, which will lead to the emulator being feature complete.

https://gitlab.com/jgemu/jollycv I pushed my code publicly a little while ago. Please note that the emulator is a "core" for my emulation framework, so you do need a development environment to use this currently, but I am perhaps open to building it as a standalone binary if there is sufficient interest. Currently there is no support for the spinner interface that is used for non-standard input devices or Super Game Module support, but I plan to add these things soon. I have a few more questions: 1. Lord of the Dungeon shows garbage on the title screen as in other emulators. Is this due to lack of SRAM support in these emulators or would other things be causing this? 2. Jungle Hunt's menu screen shows different colours in every emulator. Is this also the case with every different physical console? I played around with VDP register default values and found changing values in Control Register 1 can influence the colours, but cycle timing seems to be another factor here. 3. I am having issues with the homebrew games Black Onyx and Boxxle. Are there any known quirks with these games that I would need to handle?

It looks like that's what it was. The datasheet says 32 cycles, so I delay 32 cycles on PSG register writes and everything sounds right! Thanks, ChildOfCv.

No, I haven't emulated that. That seems like it could be a likely source of the problem though. Thanks for bringing this up.

I have this somewhat working, since I followed the documentation. The problem is that I have results similar to every emulator but CoolCV. So, there must be some tiny detail missing from the documentation that almost every emulator developer has missed. This youtube video was recorded using real hardware, so one can observe how the PCM samples should sound: https://www.youtube.com/watch?v=Dg65_jCThKs . Compare this to most emulators, and the emulators are 2x the pitch. I have been considering that there must be some other quirk beyond simply not changing the sign bit/frequency flip flop for PCM sample playback, but it's hard to figure out what that is. Experimenting has yielded nothing so far. Thank you, this helps my understanding quite a bit. This is what I had assumed, so thank you for confirming this to be the case. Yolk's on You requires the bits to be random, but I am assuming you're talking about Risky Rick here.

Hello ColecoVision community, I am working on a ColecoVision emulator with a focus on verbose documentation, to be used as an educational resource and reference - a sort of code as documentation project. I knew few of the fine details about the hardware a few weeks ago, but now I have an emulator written that is compatible with 100% of original, officially licensed games (aside from ones requiring special controllers I have not emulated, though as far as I can tell, those do run). It was written mostly by referencing datasheets, but also some .txt files that have been written by fans of the system -- I have avoided looking at other emulators' sources because I want this to be based on documentation that may be easily referenced with explanations of every last detail. Unfortunately, I have run up against some stone walls, and I was hoping that perhaps someone from this community could help me fill in some knowledge gaps. 1. I have noticed that all ColecoVision emulators I have tried have the wrong pitch for PCM sample playback, with the exception of CoolCV. Some don't play anything at all. I have this working with the wrong pitch, and there is nothing about it in the datasheet or the documentation available from SMSPower! that I used to write my SN76489AN code. When the tone generator's frequency for a channel is set to a value of 1, this enables PCM sample playback by rapidly adjusting volume and not changing the sign bit or "frequency flip-flop" as it is called in the datasheet, but there is no reference to pitch. 2. I have not found any documentation on non-standard controllers. I actually figured out the bits on my own for the standard one by using Antarctic Adventure and "voodoo programming" to brute force most of the information. I would like to emulate the Driving and Roller controllers but documentation seems sparse, so perhaps someone here could direct me to where I may find some information about these, rather than using the voodoo programming method. 3. Do any commercial releases, or even homebrew releases, use the VDP's undocumented video modes? 4. Is there any documentation or research on the RAM's startup state? Is this supposed to be a certain value or random garbage? I hope to make a public release very soon, but I would like to see if I can tie these loose ends up before I do that. I would be very appreciative of any information anyone is willing to share! Cheers