It is currently Tue Nov 21, 2017 5:28 pm

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Thu Sep 20, 2007 4:24 pm 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
greg wrote:
Great! A standard SD slot would make it much more useful for me though (I know of at least one person thinking the same). Maybe it can be put on the back of the PCB?


No, that drives up the manufacturing costs. The alternative to a MicroSD slot is no slot at all, and that's a no-brainer.

Quote:
Also make sure it isn't buggy like MMC64 (Sprites, Init).


Details please. When does it happen, what are the symptoms, what should happen but doesn't? Small, commented test routines that bug on MMC64 would be especially useful.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 20, 2007 6:10 pm 
Offline

Joined: Thu Sep 20, 2007 2:28 pm
Posts: 3
Quote:
Details please. When does it happen, what are the symptoms, what should happen but doesn't?


MMC64 corrupts data while loading with sprites activated. I think Doc Bacardi knows more about it.
Initialization seems to be problematic, too. A certain command to the SD/MMC card (CMD0) needs to be retried in many cases on MMC64, while this shouldn't be needed. On my AVR test board all cards I've ever tried work without retrying CMD0. Maybe SPI timing is a little bit off on MMC64, I don't know.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 20, 2007 6:33 pm 
Offline
User avatar

Joined: Tue Feb 20, 2007 12:05 pm
Posts: 75
Location: Toronto, CANADA
You can't please all the people all the time an given the relatively low cost of memory cards, regardless of type, my feeling is that it doesn't really matter what kind of card the device uses. As MagerValp points out, any slot is better than no slot.

_________________
Call me Golan; my parents did.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Sep 20, 2007 11:51 pm 
Offline
User avatar

Joined: Thu Jan 12, 2006 1:52 am
Posts: 203
Location: Denmark
MagerValp wrote:
greg wrote:
Also make sure it isn't buggy like MMC64 (Sprites, Init).

Details please. When does it happen, what are the symptoms, what should happen but doesn't? Small, commented test routines that bug on MMC64 would be especially useful.


Check out this thread: http://retrohackers.org/forum/viewtopic ... ght=sprite

Doc Bacardi has made a small program for testing this: http://retrohackers.org/forum/viewtopic.php?t=88 - sources included.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 21, 2007 1:03 am 
Offline

Joined: Thu Oct 19, 2006 9:42 am
Posts: 8
Hey everyone

I thought I'd drop by and elaborate a bit on the project.

First of all thanks for all the comments/suggestions. This project is still
in the prototype stage so it's still possible to improve the design.

Some facts/specs:

* Register-compatible with Super Snapshot V5. Hoping to make a RR core, or if CPLD space allows, make it RR/SS switchable with a jumper. CPLD is roughly around 45% full with the current design (still missing the SPI/SD interface though).
* 512k Flashrom, 64K sector size, 8 sectors.
* 128k SRAM
* CS8900A ethernet controller on-board, mappable to de02-de0f. (dfxx is doable too)
* MicroSD slot. Aiming for MMC64 register compatibility (for the SPI interface, probably not the rom mapping part).
* Prototype boards will be on display at the ECCC expo next week.

Other thoughts:

I got the 1GB microSD card in the picture for about $13 USD. With decent transfer software in flashrom and built-in ethernet, I'm hoping you'll rarely ever have to remove the microSD card.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 21, 2007 10:48 am 
Offline
User avatar

Joined: Thu May 18, 2006 2:17 pm
Posts: 76
Location: Kungsör, Sweden
The things I dont like about the mmc64 is the sprite bug and the lack of ram.
The sprite bug can make mmc fixing demos difficult or when not having the source code almost impossible. With the lack of ram it is necessary to plug in a retro replay to be able to use the plugins that replace the kernal routines for loading and saving data.
Also I have problems with the rr-net not working on my plastic 128d.

And it looks like this cartridge has the potential of solving all my problems. And having the ethernet port fixed on the board is a great bonus.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 21, 2007 2:08 pm 
Offline
User avatar

Joined: Sun Jun 03, 2007 6:43 am
Posts: 130
Location: Rethan Manor, Balmora, Hlaalu District
Hello. This is excellent! The picture is sexy... :lol: Any idea what the price is roughly gonna be? Hmm, the 64K sector size would be perfect for using this cart to support 8 Retro Replay ROMs at the same time. :D You could still erase and program each of them separately. My humble opinion is that honor compatibility as much as possible, but if needed yield with it in favor of better features. As long as the SPI interface is compatible with MMC64, I don't see a problem with memory mapping done differently since that should still allow most MMC64 applications to run, especially with the MMC64 having no banking at all (of on-board ROM or RAM (the non-existent one))... 8)

_________________
Commodore 128 Programmer
City of Kouvola, Finland

http://mydarkgothvampiricplace.endofthe ... Commodore/


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 21, 2007 4:16 pm 
Offline
User avatar

Joined: Thu Jan 12, 2006 1:52 am
Posts: 203
Location: Denmark
I would very much like to know about how the CS8900 is interfaced and how the actual chipselect from the C64 looks.
More specifically how are the I/O Ports mapped? I suspect just like RR-Net?
And how close is the implementation to the AN181 reference design?

What is the timing of the C64's /IO1, R/W and PHI2 in relation to the CS8900's /IOR, /IOW and CHIPSEL? - a difficult question to answer, but a timing diagram would be nice ;-) - Is C64 DOTCLK involved in that particular part?
I suspect the problems many people are having with RR-Net on C128D and SX-64 are due to the timing of the above mentioned signals simply being too "tight".. maybe because Retro Replay and MMC64 are involving DOTCLK in the mix..
Anyways, my own custom buildt clock-port without DOTCLK seems to be working on machines where RR or MMC64 + RR-Net are failing. This doesn't mean that the RR-Net's PAL logic couldn't be at fault though.

Well, this isn't about RR-Net's issues though, but I just want to make sure that we won't see any of the same problems on any NEW hardware. :wink:


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Sep 21, 2007 10:50 pm 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
FMan wrote:
Any idea what the price is roughly gonna be?


Way too early to tell, it's still just a prototype.

Devia wrote:
I would very much like to know about how the CS8900 is interfaced and how the actual chipselect from the C64 looks.
More specifically how are the I/O Ports mapped? I suspect just like RR-Net?


Yes, it's mapped like the RR-Net. You can see GuruTerm running in the last picture.

Quote:
Anyways, my own custom buildt clock-port without DOTCLK seems to be working on machines where RR or MMC64 + RR-Net are failing. This doesn't mean that the RR-Net's PAL logic couldn't be at fault though.


Can you post the schematics?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 22, 2007 1:14 am 
Offline
User avatar

Joined: Tue Feb 20, 2007 12:05 pm
Posts: 75
Location: Toronto, CANADA
Could you tell us more about how one would access the memory card? Would it work like an MMC64 or would it be able to handle multiple files? The thought of being able to quickly download a .d64 image to RAM and run something from the image is very exciting.

I spoke to Joe about this last night and his feeling was that it would be advantageous to call this something like Super Snapshot Pro so that he could continue to sell the original design (albeit with updated software) as the Super Snapshot (v5.whatever). They would compliment each other nicely if the original were available in the $50-$75 range and this model was in the $100-$150 range. Quite frankly though, I wouldn't flinch at paying $200 given that this seems to have most, if not all, of the functionality of a RR, an MMC64 and an RR-Net. You know, this has the potential to be the last cartridge anyone would ever want to buy. Freaky.

Very nice job, dW.

_________________
Call me Golan; my parents did.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 22, 2007 3:10 am 
Offline
User avatar

Joined: Thu Jan 12, 2006 1:52 am
Posts: 203
Location: Denmark
MagerValp wrote:
Devia wrote:
Anyways, my own custom buildt clock-port without DOTCLK seems to be working on machines where RR or MMC64 + RR-Net are failing. This doesn't mean that the RR-Net's PAL logic couldn't be at fault though.

Can you post the schematics?


Already did here: http://retrohackers.org/forum/viewtopic ... c&start=24


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 22, 2007 11:08 am 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
gklinger wrote:
Could you tell us more about how one would access the memory card? Would it work like an MMC64 or would it be able to handle multiple files? The thought of being able to quickly download a .d64 image to RAM and run something from the image is very exciting.


The register mapping will be compatible with the MMC64, so things like DreamLoad should work without modification. The MMC64 browser and plugins won't work, since the rom mapping is different. If you really want to run it you can probably hack it. The plan is to provide a kernal driver for the SD, making it available as a device like the IDE64, but that's a lot of code, and no one is currently working on it.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Sep 22, 2007 11:41 am 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
Devia wrote:
MagerValp wrote:
Can you post the schematics?

Already did here: http://retrohackers.org/forum/viewtopic ... c&start=24


Ah. The snappy does it with logic equations in the CPLD, and there are a few more signals in play (SS enable bit, clockport enable bit, etc), so it's hard to make a direct comparison.

I have a breadbox where the RR-Net doesn't work. I'm going to try the SS proto + RR-Net on it later this week to see if it's any better.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Sep 24, 2007 12:02 pm 
Offline

Joined: Mon Sep 24, 2007 11:32 am
Posts: 4
MagerValp wrote:
The alternative to a MicroSD slot is no slot at all, and that's a no-brainer.


Another downside of MicroSD is that it is the only SD card format for which SPI support is optional. But it's the same for MMC and I haven't seen any reports about cards in either format that don't support SPI, so this problem is probably just academic.

Too bad there isn't and standard footprint for SD card slots, otherwise you could just add pads for a larger one on the bottom (should add next to nothing to the cost, just a few holes for the vias for the signals) for those people who want to solder in one themselves.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Sep 24, 2007 8:19 pm 
Offline

Joined: Thu Oct 19, 2006 9:42 am
Posts: 8
Devia wrote:
I would very much like to know about how the CS8900 is interfaced and how the actual chipselect from the C64 looks.
More specifically how are the I/O Ports mapped? I suspect just like RR-Net?
And how close is the implementation to the AN181 reference design?

What is the timing of the C64's /IO1, R/W and PHI2 in relation to the CS8900's /IOR, /IOW and CHIPSEL? - a difficult question to answer, but a timing diagram would be nice ;-) - Is C64 DOTCLK involved in that particular part?


Lots of beefy technical questions :)

The CS8900 implementation is almost identical to the AN181 design. The noteworthy changes are that the address bus on the chip is hardwired to $0030X and AEN (CHIPSEL') is tied low.

I used one of the RJ45 connectors with built-in isolation transformers in order to save board space.

The dotclock is involved in generating IOR/IOW, mostly because I noticed some issues with signals fluctuating early on in the PHI2 high cycle. Can't remember the exact details, but I believe when acessing the flashrom, ROML/ROMH had an extra transition in the first dot clock cycle after PHI2 goes high. This caused an extra access to the flashrom and made things like sending the flash unlock sequence impossible. I used the dotclock to work around those glitches. The ior/iow signals are generated in that same block so they have the same timing.

I'll try to get some pictures of a logic analyzer trace for a read/write to the ethernet chip, but probably some time next week. I'm currently working on finishing the microSD part, and hope to have it mostly done for ECCC.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group