SvOlli

Last week, I checked if I could use the knowledge I gathered creating my own ROM dumper on the RetroN, buying one just for that. Digging through the sourcecode I was underwhelmed: no updating the firmware without soldering the firmware is written in a way that makes recreating the binary difficult, when using open source tools the design was a very bad choice I want to comment on the last one: with my ROM dumper, the microcontroller software is still in it's first incarnation. When deciding on the design, I chose that I will implement all "intelligence" about the mappers on the "host" side, and not the microcontroller. The firmware just knows the functions: POKE PEEK DUMP (multi-PEEK) POKE writes a single byte to the bus, PEEK reads a single byte, DUMP is just for speeding up things by reducing protocol overhead: it PEEKs through whole areas. And I came up with that design in something like thinking about it for 15 minutes with the focus on "what well be the easiest to debug", as well as "what would be a simple and elegant architecture"? I'm really wondering what the guy that designed the dumper of the RetroN does for a living... Originally, I assumed that the dumper just works by connecting the ROM slot to GPIOs of the CPU using level shifters. For my dumper I was evaluating this option using a Raspberry Pi as an alternative option, but using an ATmega with enough GPIOs was so much easier, as I can run it on 5V.

Here's what I would do: compile rsync for the RetroN. Then decide if it's better to run it as a server to write new ROMS to SD, or to have it check up upon startup on new data. When running with the right parameters (something like --filesize-only comes to mind) it's possible to have it just using a second or two to run the sync.

I'd rather support one step at a time: first build a good baseboard, then see what it can be plugged into. And with the baseboard utilizing a 6502, just using it as a 6507 replacement would be plain simple: connect IRQ and NMI to +5V, and keep A15, A14 and A13 unconnected. A bit more interesting would be adding a GAL chip creating the chip select signals in a way that RAM could be placed at $1000-$EFFF. Or even $1000-$FFFF that can be loaded (with an UART for example) by a small bootrom that then turns itself off. At least that was the kind of expansion that I looked into with my try to build a PCB. But that's something open to discussion once we've gathered enough substance. The other idea I had was to utilize a 6502 B which is capable of running at 3MHz. This could be overclocked to 3.57 MHz then running at the same frequency as the TIA. But this will almost certainly not work, because there's a feedback from the CPU frequency back into the TIA. Also the 6502 B is way much harder to source than the 6507. Rereading what I've just written, I noted that if done right, the "RAM expansion" can be done _outside_ of the baseboard, if the baseboard has slightly more output that just the cartridge port pins. If we use just standard 2.54mm connectors, the other side could be either a cartridge slot, or that vaporware RAM board, if not only D0-D7 and A0-A12 get put on this connector, but (at least) A13-A15 and R/W as well. That way we'd still have the "pure-with-6502" option, as well as the RAM board one, based on the same baseboard. I am absolutely positive that a PCB with two CPU sockets (one for 6507, the other for 6502) would be possible, if only one of those two has a chip put in it. A bit more tricky will be trying to allow both PAL and NTSC TIA fitting. The solution I came up with so far would need at least some jumpers. Looking forward for this project to throw my 2c and work in it.

Since it's been quite some time, I can't remember for sure. But I think I found some German reseller on eBay who charged for a single one about as much as your find wants to have for a pack of 10.

Yes, now it's tested, and I can tell which bytes differ between download and cartridge.

Fine, now I can dump my effort on doing a 2600 board. The CPU board idea is quite interesting, since I wanted to do a version that's as compact as possible. What also could be nice would be an option to use a 6502 instead of the 6507, since those are easier to source.

It is yet untested, as the package arrived, when I was out for groceries. It I had known, I would have skipped the groceries. Test will be conducted soon.

Here's some code I use for bankswitching. It's a modified version of the code used in Bang! There it's done with code generation, so this code differs. The cool part is that the banks are encoded in the upper 3 bits of the address when jumping to a routine. Note the comments when trying to use it, some lines need to be removed according to the bankswitching used. There is a frontend used by macros that enable the jumping across banks, as well as for RTS. These need A and X for calculating the bank and the jump. The backend expects the code for calculating the jump at the same address in each bank. I suggest ti put it directly before the bankswitching hotspots. Also note that the RTS will trigger a read on the following byte, so putting this before the hotspots is a very bad idea. ; macros for using ; all bankjumps overwrite A and X registers .macro bankjsr _addr ldx #<(_addr-1) lda #>(_addr-1) jsr bankjmpcode .endmacro .macro bankjmp _addr ldx #<(_addr-1) lda #>(_addr-1) jmp bankjmpcode .endmacro .macro bankrts jmp bankrtscode .endmacro ; this code needs to be replicated to all banks ; to the exact same address bankjmpcode: pha txa pha bankrtscode: tsx lda $02,x asl rol ; remove when F8 rol ; remove when F8 or F6 rol and #%00000111 ; use this for F4 and #%00000011 ; use this for F6 and #%00000001 ; use this for F8 tax lda $fff4,x ; use this for F4 lda $fff6,x ; use this for F6 lda $fff8,x ; use this for F8 rts bankreset: lda $fff4 + (reset >> 13) ; use this for F4 lda $fff6 + (reset >> 14) ; use this for F6 lda $fff8 + (reset >> 15) ; use this for F8 jmp reset ; this is padding for the bankswitch bytes .byte $f4,$f5,$f6,$f7,$f8,$f9,$fa,$fb ; use this for F4 .byte $f6,$f7,$f8,$f9,$ff,$ff ; use this for F6 .byte $f8,$f9,$ff,$ff ; use this for F8 ; reset vector .word bankreset ; irq vector .word bankreset For me this was some kind of the golden solution to the "bankswitch-problem". Still you need to keep code and data in the same bank, but for my demo this never was a problem... Also note, as these code fragments are taken out of the demo and modified for this discussion, so there might be bugs in there. If so, let me know, and I'll try to fix this. The demo was also coded using ca65 so the syntax for other assemblers might differ.

If it's just about an index for an animation, I would do it the other way round: counting down, so you can spare the compare: ldx counter dex bpl @noreset ldx #$02 @noreset: stx counter All you need is to reverse the order of the animation frames. But Andrew's a bit faster... of course. But mine's one byte shorter.

Is this code tested? I'm wondering how this possibly could work since it's not handling chip select, so it's corrupting the data bus, if anything else, like RAM, is selected.

So what? Defeating most (if not all) types of encryption is easy. All you have to do is to implement a trigger for bankswitching, which is not too complicated after dumping and disassembling the first bank. Only way I know to defeat this is using a Harmony/Melody board with code running in the ARM microcontroller.

Found it! It's at 17:44 in this video: But I recommend watching the whole video.

I picked the wrong video, without verifying it. I remember viewing a talk by David Crane about Grand Prix, where he stated that they were lucky that the bug was never fixed, because they could use it to hide the "wrapping around" of sprites. I looked through my archives, but can't seem to find it... strange. Maybe someone else can step in here. Or I can dig it up later.

As Master Phruby already pointed out, it is part of the design of the TIA. Consider it a bug in the chip that was turned into a feature for some use cases, like David Crane described it in his talk about Grand Prix:

Not a killer hack, but still something I found useful. For easy notation: "A" means accumulator, "R" is a value stored in RAM. So, doing "A minus R" is easy SEC SBC R I was faced with the problem of doing "R minus A", remembering of something I learned at school called "2s complement", I came up with this: EOR #$FF SEC ADC R So, what I did there was "minus A plus R". And it worked like a charm with a "cost" of two bytes and two cycles. And also: That's a very nice idea. But "spending" 1/16 of a bank seems to be a bit expensive. But coding for coding for other 6502 based platforms (C128/C64 right now), I will definitely use this, as the table could be also created with a simple loop in RAM. (That would be a fun thing in SuperCharger.) Thanks!

When I did the research for my talk a couple of years ago, I found an advertisement for development system that was an expansion cart for the Apple II that had a daughterboard that would go into the 2600. But doing a quick search now, I couldn't find any of those stuff any more. Edit: d'oh! I should click on the links of the other posts before posting myself. The Frob is most probably the dev-system I've seen a couple of years ago, though I only found an advertisement back then.

I've gone to using TIMINT very early in my efforts to get code running. Since it's long ago and I'm using my old code ever since unchanged, there's how I remember it: - just write to TIMxTI instead of TIMxT (it might be that the ...TI is not defined in vcs.h, then go for (...T | 0x8) - instead of waiting for the timer to zero out, I'm waiting using a loop like this: "@loop: bit TIMINT : bpl @loop" And that was all. If you like, you can take a look at the code of all of my releases. They are available at: https://xayax.net/ . A rather simple demo is this: http://xayax.net/2k_is_no_limit/ . I've got three functions (in main.s) there "waitvblank", "waitscreen" are called using "jsr" and just wait until the beam has passed these areas. "waitoverscan" is called using jump and does more than just waiting, as it contains logic to decide on what to run in the next frame and generates the sync signal.

There has been a new release of "No More Secrets" recently, v0.95: https://csdb.dk/release/?id=198357 This is a documentation of what the "illegal opcodes" do in detail. Deep detail. Very deep detail. The main focus is on the C64, but most of the document applies to the VCS as well.

I remember it was noticed in one of the videos I watched to prepare for my Ultimate Atari 2600 Talk. I think it was Joe Decuir who stated that they originally had 256 colors, 16 colors, and 16 hues. During development they noticed that 4 bits of hue led to being those colors "to close to each other" and that they could spare a couple of transistors on the chip just by dropping the least significant bit.

Nevertheless, how about an option to put PlusCart in a listening mode? It then will listen on a defined port (like 2600) that will get the binary payload just like a file sent to this port with a tool like netcat. This payload will then be handled just like a ROM downloaded. My guess is that this could be implemented rather easy. And if "start in listen mode" could be bound to something like the "B/W" switch upon power on, PlusCart would also make a very useful tool for a homebrew developer. Just my 2 cent that came up while reading this thread.

I think I did and got a "no" as well. But that was a couple years ago, so I might be remembering this wrong (as well as the "direction" of the one cycle being off).

Too early, are you sure? You're right. One CPU cycle too late. Just checked with actual hardware. I was assuming that the shadow read from the ",X" was triggering the FPGA instead of a write. Nevertheless, I reported the bug and got a "sorry, no time, won't fix" as a reply. Sadly the project is not open source, so no one else can try to fix it. I even found someone at our hackerspace who would have helped me to get into FPGA coding.

Yes, I ran into that problem with my demo "Bang!" during one part. I noticed that an STA BGCOL,X is triggered on cycle to early, so a colour change that was hidden with a sprite is now visible. That led me to switching back to a composite modded 2600 jr again.

These are EEPROMs, but have the pinout of a standard 27(c)256 EPROM. And for your setup: yes, there are some advantages. But for me Stella is so close to the real thing and offers the best debugger I've seen so far. Period. So running a cycle with Harmony Cart in USB-mode (not using the SD card) or SuperCharger is close enough for final testing, even though I have to power cycle manually. So what I'm saying here, for me I've got enough hardware that fits well enough. But if I had an EPROM simulator already I'd gone for something very similar. So congrats for a project well done.

I've gone a slightly different way: I asked Al to build me four EPROM PCBs: 4K, F8, F6, F4 with sockets instead of EPROMs. In each of those sockets I put in a ZIF-socket (aka Textool socket). And for those sockets I've got 27SF256 EEPROMs, which can be reprogrammed without going through the UV-erase phase using my first gen MiniPro TL866. Works like a charm. Slightly more complicated to use, but solder-free (at least for me), versatile (can run "standard" 4k-32k ROMs), and a bit less cost intensive (considering I already had the MiniPro).