cdoty

I have a problem hitting the up direction on the directional ring with my thumb. It's way too easy to do. The A500 controller works on The 400. That's what I'm using for now.

This seems to suggest it's ran by an RP2040 microcontroller. http://emwires.com/Colecovision/index.html

The Creativision is 6502. Can RAM be mapped to the cartridge port on the Colecovision? The PV-2000 has 4k and Colecovision+ has up to 24k. I'm thinking the exact opposite. Everything, other than standard Colecovision mode, is emulated to some degree. I think there's a passthrough of TMS-99x8 and SN76489 data.

I wonder if this is the reason they limited the Atari 2600+ to 2600 and 7800 games, leaving the 5200 stuff for the The400? The keypad is another problem, but neither system has a full keypad. I was thinking the 4 keys around the LED might be part of the 7 keys supported on the device.

That could be an advantage of physical media, and the game could still be played in emulators without the LED.

I'm guessing they are emulating the non-Coleco systems and pumping the TMS-99x8 data through the Colecovision's TMS-9918a. This could explain the issue with parts of the screen not updating correctly. There just isn't enough time to get the data to the VDP before the frame draws on the TV, especially on non-static backgrounds. The same seems to be happening with the SN76489 data. From the description, there seems to be some attempt at converting the AY-3-8910 data to SN6489 where they can also.

She goes through a bit more of the history of the cards in this video: She has a ton on fascinating stories.

Plug it directly into a computer? It worked fine for the NES and SNES mini.

I'm sure these systems could be emulated on a toaster. Unless more modern chipsets are cheaper, it's overkill to use them. Similar SOCs power most mini consoles.

It's a C like compiler paired with an assembler, similar to something like Millfork. Many of Inufuto's releases have source code, which are compiled with this compiler.

The loader is from Invaders. It's the part2.CAQ file. I'm not sure of the limitations.

The big difference between Millfork and Z88dk, SDCC, etc. is that it allows a lot closer integration between assembly and the C like language. You don't have to jump through hoops to expose an assembly language function to C, etc. Defining macros is also a lot easier than any assembler I've used before. From a software development standpoint, it's easier to create understandable assembly language code, as parts can be written in macros, which look just like normal function calls. This allows large functions to be broken down into pieces without adding overhead for function calls and parameter stack pushing. The code isn't as optimized as assembly, of course, but it's actually not bad. It will only include functions and data that is referenced in code. Of the 4.3k size, half is screen and color data. I added a release with the cartridge binary, and the CAQ and Wave files for the cassette version. I hadn't thought about the binaries, thank you. I also fixed some issues with the mk.bat and mktape.bat files, in the Cart folder. It should build under Windows without any additional software or setup. I would not recommend using the Gameboy tools for graphics. It's overly complex for what is needed, but it was the only thing that I could initially get set up to use the ROM character set. I am in the process of switching to Aquarius Draw.

I put up a github repo with a working example using the Millfork compiler, Visual Studio Code, and MAME for debugging. https://github.com/cdoty/Aquarius-Millfork

I am interested in one.

Will contact through DM.