And what code is needed for disabling that clock port again? (hopefully you cant
)
| retrohackers.org http://retrohackers.org/ |
|
| RR-Net coders, please adjust your init routines http://retrohackers.org/viewtopic.php?f=5&t=177 |
Page 1 of 1 |
| Author: | MagerValp [ Sun Oct 15, 2006 2:41 pm ] |
| Post subject: | RR-Net coders, please adjust your init routines |
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: Code: lda #$a1
sta $de01 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. |
|
| Author: | Devia [ Mon Oct 16, 2006 1:42 pm ] |
| Post subject: | |
And what code is needed for disabling that clock port again? (hopefully you cant )
|
|
| Author: | MagerValp [ Mon Oct 16, 2006 8:18 pm ] |
| Post subject: | |
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. |
|
| Author: | RaveGuru [ Tue Oct 17, 2006 11:50 am ] |
| Post subject: | |
Where can we find more info about this wicked new cart ? 
|
|
| Author: | MagerValp [ Tue Oct 17, 2006 5:28 pm ] |
| Post subject: | |
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. |
|
| Author: | dW [ Thu Oct 19, 2006 9:15 am ] |
| Post subject: | New cartridge specs |
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. |
|
| Author: | RaveGuru [ Thu Oct 19, 2006 10:34 pm ] |
| Post subject: | |
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... |
|
| Author: | MagerValp [ Fri Oct 20, 2006 8:06 am ] |
| Post subject: | |
Looking for signature bytes at $dexx should work. |
|
| Author: | dW [ Fri Oct 20, 2006 8:08 am ] |
| Post subject: | |
RaveGuru wrote: 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... 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? |
|
| Author: | tnt/beyond force [ Fri Oct 20, 2006 10:01 am ] |
| Post subject: | |
MagerValp wrote: Looking for signature bytes at $dexx should work.
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.)
|
|
| Author: | MagerValp [ Sat Oct 21, 2006 7:22 am ] |
| Post subject: | |
tnt/beyond force wrote: MagerValp wrote: Looking for signature bytes at $dexx should work. 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. |
|
| Author: | RaveGuru [ Sat Oct 21, 2006 6:08 pm ] |
| Post subject: | |
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 |
|
| Page 1 of 1 | All times are UTC [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|
