SvOlli

Yeah, yeah. Always on the non native speakers... "right" as in "opposite of wrong". But most EPROM programmers want notch neither left nor right, but at the top... ?

You might not have to go for a 2600 dumper. A standard EPROM programmer should be capable of reading the EPROM, if pulled from the socket. The TL866, a very common device will accomplish this for example. Just make sure you line up the pins correctly. And that the notch is on the right side, EPROMs are not very forgiving about this and lose their magic smoke. After a successful dump, it might be case, that some address of data lines are switched (either for "encryption" or just to make the layout of the PCB "easier"). Nevertheless, this can be resolved by matching the pins of the socket to the cartridge connector using a voltmeter in continuity mode. Then those changes can be reproduced in a small "conversion tool" then. But an easy first step might also be plugging it into a 2600 and post some screenshots here. At least the game will be most probably identified this way.

This is a kind of attitude, that I would like to see from professionals, who like to distinguish themselves from homebrewers, and have sold faulty cartridges for a steep price earlier this year!

Then you might want to take a look here: https://www.raspberrypi.org/blog/raspberry-pi-rp2040-on-sale/ It's the official blog from the Raspberry Pi Foundation. And they point to here: https://www.raspberrypi.org/products/rp2040/ And on the buy button you get five options of which this one looks best to me: https://www.okdo.com/us/p/raspberry-pi-rp2040-microcontroller-pack-of-10/?src=raspberrypi My favourite and trustworthy source for all Raspberry Pi stuff (Berrybase.de) is listed in the Germany sections, and they sell them for 99 Eurocent a piece up to 10 pieces per order. Hope this helps, SvOlli

I suggest to click you way through the official resellers list of the Foundation product page: https://www.raspberrypi.org/products/raspberry-pi-pico/ My first try was PiShop.us and I could put 50 in the basket. Bonus: afaik, you can even get the chip alone for soldering into your own projects, but I'd have to verify that info from the official Rasperry Pi Foundation Blog.

Here Ben sacrifices a 2600 to get the chips. The question was to build a new one, not convert one to another form.

Great list, great explanations! Did you also find any informations about the single-chip clones?

You know about MOnSter 6502? Now take the following into account: the TIA uses more transistors than the 6502 the MOnSter 6502 has (or at least had) problems to run at 1 MHz, the TIA requires 3.57MHz So the answer to your question is theoretically: yes, but you'll can't call it "easy" or "easier" in any way. A well meant tip: it you really want to recreate the TIA, use a programmable logic IC suitable for this: an FPGA. You wouldn't want to go to the tour de France in a clown cycle, or do you? They used stacks of wirewrap boards for this. Did you know that they only ran at full speed, once the design was transferred to a chip? And did you know, that the TIA was also designed the same way and even by the same person was involved (Jay Miner)? And back then at the same time, CPUs were designed by drawing on paper and shrinking these images down and projecting them onto the wavers. Nobody does that any more, because development has advanced. So what's your point? If you want to recreate the 2600, and you focus on the three chips, where are your options: CPU new CMOS 65c02 (not all software will work) old new stock 6507, but those are not easy to get old new stock NMOS 6502 with an adapter FPGA replacement RIOT old new stock 6532, i found some rather easy on ebay FPGA replacement TIA old new stock TIAs, those are hard to find FPGA replacement And if you've got FPGA replacements for all three chips, you could think about joining them in one, recreating the legendary Janus chip. This was the approach of the Flashback II, but it was only half-baked, though. Development stopped, when all games included with the console worked. A lot of corner cases of other software were not covered.

Thanks. The video helped me to get a quite some understanding. My problems with CoRoBars were experienced on a PAL machine, so that "bad linecount" by not being constant in the up vs down movement does not make the video "trip" on NTSC as it does on PAL. And it's also good to know that the hard2632 technique does also work. That's knowledge will be handy when hacking up a 32 byte demo or even on a 256 bytes demo.

To put my two cents into one sentence: it was okay back then, but today one should be ashamed of not using 262 or 312 lines. Especially with Stella to help you accomplish this. There might be reasons like tape loading or sampled music that requires to drop VSYNC completely, but otherwise I consider it a stupid beginner's mistake. In the demoscene there are now some people who are also trying to use the 2600 for a quick product (compofiller) in an emulator or online dev environment. When it looks good there, it will be released. The best example is CoRoBars which looks nice in an emulator and like goat barf on real hardware. @ZeroPage Homebrew : Could you please run a quick test with my 32 bytes demo hard2632? During development, @Thomas Jentzsch and I were discussing if using just VSYNC is enough, of if VBLANK is also required for having a correct display. We settled for "if you do it in 32 bytes, there will be no space left for a demo effect". But it would be very nice to have a second opinion by the Framemeister.

Hello there! Another idea that's traversing through my mind is to take the original Adventure code and make it something like "multiplatform" by separating the game logic from the input and output, so that the game can then be ported rather easy to other 6502 based platforms like the C64, C16/Plus4, Apple II series and alike. In a later step, expanding the kingdom would be also an option. But to evaluate if this is feasible with an amount of effort I can spend on this project, I'd like to read through some disassembly. I know of the one hosted on the minidig, and while this one is a start, I found a couple of things that could be improved in the first two minutes. When I started working on that sourcecode, I wondered if there is some better around. Looking at all the Adventure hacks around, I assume chances are high, but I didn't find one so far. So I decided to ask around here. And of course, once I've got something to share, I'll set up a git repository for it for others to join in.

Well, I stated "come" not "came". So I'm still convinced that this will be fun: having a Raspberry Pi Zero W integrated as development system and to configure the behaviour of the "addressmapping". But there might be coming some major drawbacks, beginning with Stella being unaware a CPU with an 16-bit address bus. So there are a couple of downsides, but I still would consider this fun to build. Also the Raspberry Pi can be used to trigger reset, irq and/or nmi for debugging purposes.

I've just watched the latest episode of Adrians Digital Basement on YouTube, where he tool the ROMulator for a testdrive on a VIC-20. So there I got the idea: replace the 6507 of the 2600 with a self-built 6507 to 6502 Adapter, and then use the ROMulator to create a VCS with an addressable space of the full 64k without banking. So I ordered one, before I come the the conclusion that this is a dumb idea. I also need to figure out which one of my 2600s will be the hone hosting the Frankensteins monster, or if I want to buy a new one...

Now that I needed to dig out my dumper for a test run I've got some more reliable numbers: the Teensy++ 2.0 it takes about 1.1s for dumping 1k of data. These also have been some code changes to the Teensy++ 2.0 firmware. But these are purely cosmetic. The intention is to make maintaining more that one board at bit easier.

Is the Nano based upon the 328P or the 168P? From my different projects I noticed that the 168P gets programmed using something like 19200 instead of 57600 or 115200 like the 328P. I'm pretty sure that this was for a reason...

I've never optimized it for speed, I just wanted to dump some ROMs for running in an emulator and Uno Cart 2600. The transfer protocol is also intentionally kept simple, so there's less chance for errors: all data transfer is encoded in hex instead of binary. This divides the transfer time by two. Also the Baud rate is selected very conservative with 38400, more on the stability side, since I had problems running on 115200.

I've used the Teensy, because a Nano does not have enough GPIOs. We need as a bare minimum: 13 for address lines (bidirectional) 8 for data lines (also bidirectional, required for 3F bankswitching for example) 2 for UART (1 input, 1 output) An Arduino Nano has: 2 for UART (D0, D1) 11 digital (D2-D13) 6 analog/digital (A0-A5) 2 pure analog (A6, A7), which won't work So that's 23 required vs 19 available, and I have no idea how this could be made working without some additional hardware.

Yes, it was. But SARA was implemented using the Harmony Cart (or Melody for the releases). And since last year, I finally have a physical SARA board with the demo on it. And also, I can write code that only runs on the Harmony with SARA emulation, but not on real hardware. Do code generation in SARA RAM and try to execute it. "Bang!" does contain code generation for the plasma effect, so there was a chance of encountering this problem.

Hello! Last month there was a release of a music video done with the Atari Video Music. The artist, Dick Dent asked me last year, if I could visualize an upcoming release of his, "Click of the Fingers". Here the video: And a bit more of the background can be found at my Atari Video Music page.

And to the topic at hand: on a demoscene competition, only code that works without the microcontrollers are considered "old school". A demo using DPC+ or any other ARM-based coprocessor would be submitted as a "wild" entry, which is the "does not fit any other category" / "catch all category". This is also why I did a "SARA" version of my demo "Bang!", just to make sure once and for all that it's not just theoretically "old school", but also practically.

Thanks for letting me know. All the stuff I release is done without any tracking. For my demos I don't have a download counter, I only log errors, no successful accesses to my server. So it's getting any kind of feedback is rather scarce and very much appreciated.

Well you can try to set the baud rate down. With 9600 baud, the transfer might become more stable, even though a dump will take significantly more time. But since you only need to dump once... Edit: you need to change this in the source code and compile both sides, host and Arduino.

Whow... I might have just found a shortcut: https://github.com/baldengineer/bit-preserve/tree/master/Atari/Atari2600/C012283.RevB Spoiler: schmatics recreated in KiCAD, no PCB, but still better than converting on your own. Seems to be from a PAL machine.

...and taking a look at the build system, I suggest to use sftpserver as a blueprint: - create a new directory app/rsync - copy app/sftpserver/Makefile to app/rsync/Makefile - get the rsync source code by running "cd app/rsync ; git clone https://github.com/WayneD/rsync.git" (you might want to select a release tag instead of the head version) - now comes the hard part: adjust the app/rsync/Makefile that it runs the build process of app/rsync/rsync correctly - in the top-level Makefile duplicate every line containing "sftpserver" and replace "sftpserver" with "rsync" in that second instance - once you've come so far, add config files and or scripting for running rsync upon startup Finally you can create an sd card image that supports network updating of the ROMs. Welcome to the wonderful world of embedded development. Hint: you don't want to take a shortcut that will leave you with something you can't reproduce. And another two cents: looking at the effort it takes to get this approach done, this might look like a lot. It is. But every other option discussed so far will result in a bigger effort with greater chance of a fail. I do embedded development for a living and for fun in my spare time (besides retro stuff), so I've gained experience in estimating efforts and chances of success. @DirtyHairy: You told me that you're not a fan of the build system done by Hyperkin. Let me assure you, I've seen worse. Much worse. Done by a company who needs to get certification for their code.

@Thomas Jentzsch: Yes, that seems to help! I had to pad out the SWITCH_BANK macro with a NOP: I ran into that same problem hacking on code that uses the Arcadia Supercharger bankswitching. This is also why I put the reset routine directly before the bankswitch hotspots in my example code, as the JMP does not do a "dummy read". Also not only RTS, but every single byte instruction triggers a "dummy read" of the following address. So the byte after an "INX" for example is read twice. But that's always unnoticed.