Hi :)

A new cartridge with a clockport was demoed at the ECCC a couple of weeks ago. It's a clone of the SuperSnapshot v5, with 512 kB flash rom, 128 kB ram, and a clockport. Like the RetroReplay it has config registers at $de00 and $de01, but unfortunately it wasn't possible for dW/Style (who's developing it) to put the clockport enable bit at bit 0 in $de01. The good news is that the value needed to enable the clockport, $a1, also works on the RetroReplay. Thus, if you change your init code to do:



your programs will work on both RetroReplay, and the new SuperSnapshot. I actually don't know how the MMC64 config registers work, but the programs I've written lately (well, udpslave :), seems to work as well.

And what code is needed for disabling that clock port again? (hopefully you cant )

Ah, good point... Currently there's no value that's compatible between both. It's not too late for dW to update the CPLD though. Stay tuned - he's thinking about changing it to $81 to enable and $80 to disable.

Where can we find more info about this wicked new cart ?

As it's still in the (fully working) prototype stage, there's no official info out there. You can see a closeup of the cartridge here:

http://www.burninghorizon.com/gallery2/ ... 9.JPG.html

The specs are:

SuperSnapshot v5 compatible hardware
512 kB Flash ROM
128 kB SRAM
Clock port

Like the SSv5 it has a write only config register at $dexx (just write to any address), and read only ROM mapped to $de00-$deff. $dfxx is free for REU or what-have-you. The $dexx register is expanded with a couple of extra address bits, just like the RR wrt the AR. There's an extra write only register at $de01 that controls the clock port and flashing.

Hello everyone

I wanted to take this opportunity to talk a little bit about the new SSv5-compatible hardware I've been designing on and off for the past couple of years or so.

First, thanks to MV and jcompton for pointing me to this forum and this thread in particular

As MV was kind enough to mention, the hardware consists of a 512KB FlashROM (AMD, very similar to the RR's), 128K SRAM, a clockport, and a Xilinx CPLD to glue everything together.

The hardware has been successfully tested with the C64, C64C, 128, and SX64 thus far.

It currently runs the latest SSv5 ROM (v5.22) without any modifications.

The idea for now is to implement a FlashROM based filesystem to keep your utilities/tools there, and integrate MV's udpslave into the ROM as a codenet alternative. The Flash filesystem should open up quite a few possibilities for storing configuration data (F-keys, IP Address, etc), in order to make the cart customizable to each user's preferences.

We are also trying to reach an agreement with the current owner of the rights to the SS ROM (and source code) in order to make this an 'official' next generation Super Snapshot

One of the things currently being considered is the 'extended' SS register, in particular, how the clock port will be enabled/disabled while remaining compatible with the existing SSv5 ROM, and doing it in a way that doesn't break RR compatibility that bad. For now the clockport is enabled by poking $21 to $de01. Bit 5 was chosen as a 'magic extended register enable bit' because it is unused in normal RR operation (SS ROM uses bit 0 of $de01 for other purposes).

I will post a detailed programming doc as soon as the hardware is finalized.

This sounds very exciting, and I'm sure there are people here on the forum that would like to share some thoghts and experience about the register configuration.

The only question I have at the moment is whether there will be a way to explicitly detect this cartridge from a software point of view?

Looking forward to hear more...

Looking for signature bytes at $dexx should work.

Thanks for the positive comments

I guess one way to detect it would be to write a routine that sits below $1000. The routine could write a 'magic' string to ram above $1000, enable ultimax mode and try to verify that string. Storing $00 to $de01 enables ultimax in SSv5 (on the RR and MMC it'll just disable the clockport).

It's worth mentioning that the SSv5 register is write-only, and the rom code uses stuff like inc/dec $de01 (reads the value from SSROM, performs the inc/dec, then stores it to the snapshot register). Making the register read/write on my cart could have some unwanted side effects.

Comments?

Definition of work: "crash if one has Action Replay" . (Well, IMHO the best way to deal with AR is to disable it before any other $dexx access.)

Ah, I forgot about the lame AR hardware...

So yeah, detect AR first, then check for other carts.

Good point. We should write a check-list

1. Disable AR (is there a safe way to detect AR?)
2. Do the $de01->Ultimax test
3. Avoid INC/DEC @ $de01
...to be continued