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.

Yeah, that's where the idea came to try the 1541, since it's more readily available, and broken ones are all over ebay.

I wonder if the keyboard "Enhanced" sticker was replaced on the upgrade.

I couldn't figure out how to add a breakpoint. The rest of it looks pretty clean.

I've been playing a decent amount of Kangaroo recently on the Atari 2600, Pandora's Box, and the Switch arcade version. This definitely looks like it would be a lot of fun to play. Kangaroo is an excellent way to test joysticks on the Atari 2600.

I was finally able to locate a F18a chip and finally able to test out a program on the AppleTi card in an Apple IIgs. Here's the Apple II/AppleTi port of a simple graphics program that runs on various computers with a TMS 9918a based graphics chip. https://github.com/cdoty/9918-Adventures/tree/main/AppleII

I had a bad 1541, so I gave it a try. It works fine on both the 328 and 728. I don't have a 318 to test. It ran the MSX mapper cart and a normal cart, just find, so I'm guessing there's enough power there.

It looks like a defective Commodore 1541 drive power supply could be used. According to the service manual, pins 1 and 4 supply about 16v AC and 2 and 3 supply 9v AC. http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1541/1540-1541_Disk_Drive_Service_Manual_314002-01_(1985_Nov).pdf An Adrian's Digital Basement video shows the power supply wires with colors that seem to match the pinout. Orange should be 16v AC and purple should be 9v AC. I do get 16v AC and 10v AC out of the expected wires.

Looking at the board here: It looks like you could just replace the 2764 eprom chip. Given that a 2764 can be problematic to program sometimes, I would recommend using a 27c256, or an eeprom equivilant, and duplicating the bios 4 times. Or if you want to make a switchable version, combined the bios files and duplicate that once.

I did the reverse to the Colecovision.. To use two bioses, I just followed the instructions for a dual boot Coleco bios, but used the modified Pencil II bios as the second one. I imagine the same process would work for the Pencil II.

I can look at the disassembly. A single byte would most likely be a different value loaded into a register. Changing an opcode would involve a larger change. The easiest way would be to load it into MAME with the debugger enabled, and disassemble memory at the location, at the location - 1, at the location - 2, and at the location - 3. On Mame, click on Debug->New Disassembly Window. Enter the address, in hexadecimal, into the top level box and press Enter. You will see the disassembly below. The bytes, to the right, will show you the values involved in the disassembly. If you find what looks like a valid disassembly, compare it to the other versions.