Snapshot actually boots in ultimax mode, with cart rom at e000-ffff and cart ram at 8000-9fff

/GAME and /EXROM are controlled by writing to the snapshot register at $de00/de01 (deXX on the original SSv5).

The original SSv5 leaves the df00 area free for the REU. My cart does the same except for the SPI i/o and control registers at $df10/11, so, no, cart RAM is not currently mappable to $dfxx).

This may change as I continue work on the AR compat mode, but for now writing code to support microSD and ethernet is the priority.

Awesome!!!

As soon as this will be available i'd buy one i guess
As for the CS8900A on this cart: Would it also be possible to implement registers that enable you to use the chips memory mode? This would make networking much easier, (retransmissions, receive packages without usung C64 RAM).
As for the ROM it would be nice to have a proper initalization of the CS8900A + setup of an IP and MAC-adress already included. So as for networking i'd be willing to help, fiddled around a lot with the rr-net in combination with 64net/2.

Why would memory mode be needed for that? You can also access the 8900 ram in packet page mode.



Yep, config will be stored the flash, and the 8900 inited at boot.

Sure, but you can only read/write data only once, and then not access it again. For example to change the header/size information and such before sending. This would allow you to first put an unknown ammont of data in teh send buffer and then just in the end calculate the checksum and size information when you are really about to send. In packet mode you have to prepare a complete packat with chksum and size all fixed before sending and need to store it at some other RAM location.
That is okay for only playing around, but not when doing stuff from ROM/Kernal, while wanting all C64 RAM being untouched. In my case i circumvented such problems by starting a packet with maximum size and then padding the left bytes and adding my own size information as the end. Okay if you do an own protocoll as 64net uses, but life could be easier with memory mode

Good thing the Snappy comes with 128 kB of ram then, eh? :)

Well, sure, but as already in the RR accessing the RAM is rather painful and slow, so not really what will give me fast loading/saving results vie network drive (~50kb/s at the moment) Also this would imply to copy the packet twice, to Snappy RAM first, then when about to send to the CS8900A buffer. Sorry for being choosy in this issue

I want one of those and I don't care about the price! :D

Things I want to add:

- MMC-sprite-bug: It just occurs with Sprite 0. Oliver Achten found out, that its fetch occurs half(?) a cycle later than the usual sprite fetches. It is an anomaly which probably makes MMC fail.

- MMC-compatibility: Somehow I understand the advantages of being compatible. But please also see, that MMC-registers have design flaws. Like, one very important bit (SPI ready) is in $DF12 at Bit 0 while Bits 6+7 are unused. This is evil! Important bits always have to be bits 6 and 7, so they can easily be checked with BIT instead if masking with LDA + AND, which usually means storing the accumulator in a temp-variable. (SuperCPU has a dozen of status-registers ONLY using Bits 6+7 :)).

I mean, Plugins won't work anyway without porting. And if you are afraid of DreamLoad not working, don' worry - we are still here and working on it :D

Ninja, since Oliver Achten knows about the sprite bug and cause, do you know if theres any chance of it getting fixed?

hollowman: I hear they are working on a new revision, dunno if this will be adressed.

How far away is this card can it be sold then firmware upgraded later to get it all working or is the final hardware not finished.

If its just the firmware i would buy then upgrade it later.

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.

Any news on the availability of the Snappy?

We've been working on integrating basic software support for the microSD card and ethernet to the existing SSV5.22 rom.

After that I have to finalize the hardware (add that hole in the middle, fix some compatibility issues, etc.).

I may do a small run of developer boards before doing a production run if enough people are interested in helping out with the software side. Still haven't decided on this. There are currently 4 boards out there (including mine) in the hands of Style members. I also have partial emulation of the new features working under Vice 1.22, which should help with the software development.

There is no formal agreement for including the existing V5.22 ROM with the new cart yet, but the new features can always be released as patches if need be.

So, to answer your question, it'll probably take till the third quarter of this year for a full production run, with a possible small run for developers sooner.

Is it too late to ask for additional features? I love my Super Snapshot 5. Quite simply my favorite cart of all time and I will be buying one of these. The only thing I really ever wanted for my Super Snapshot was a save-with-replace feature in the ML monitor. Is it possible to add that? It could be as an "SR" command or a prompt asking if I want to replace when I use "S" to save the file.

I don't know if you've gotten this worked out yet about the hole size and location, but I thought I'd chip in my two cents.

I got the C64NIC back and the hole drilled was not what I specified so I can't really say if I got it right or not. And, I can't find any trace of a hole in the Solakian cart template at the link above. I even tried downloading it again and viewed all layers and I can't find a hole in that file anywhere. Am I missing something?

I'm using an old KoalaPainter cartridge (it is in a Solakian case) and PCB as a reference, but I don't know how accurate it is compared to the newer carts. I'm using a digital vernier caliper to measure and this is what I get:

Post Diameter: 5.62mm (0.221")
Hole diameter: 5.70mm (0.225")

Board Width: 57.91mm (2.280")

Board on left side of hole: 26.29mm (1.035")
Board on right side of hole: 26.03mm (1.025")

So it looks like the hole isn't actually centered at all! I find that just funky. I have some i-comp cases on the way so I'll measure those when they get here to see if I get the same numbers and will confirm with you here unless you let me know you already have the center hole figured out.