Savegame drive idea

For hardware talk only (please avoid ROM dumper stuff)
Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Mon Mar 21, 2016 12:52 am

Most of the cost would go in the custom mold anyway.

Also one of the reasons I want to avoid SD cards is that then you'll be expected to cope with the FAT32 format (or worse, ExFAT), which makes things significantly more complex compared to a custom simpler filesystem. Not to mention having to cope with larger sectors, which will definitely hurt with bitbanging (at which point you probably want something to do the bitbanging for you so the 68000 reads whole bytes off it instead). Also, it's not fun when you have a drive with several GBs worth of space =P

If a custom cartridge (mold included) is cheaper though, we may as well just add a port there...
Sik is pronounced as "seek", not as "sick".

cero
Very interested
Posts: 338
Joined: Mon Nov 30, 2015 1:55 pm

Re: Savegame drive idea

Post by cero » Mon Mar 21, 2016 9:41 am

Why bother with a mold (~10k) when the userbase is likely just a few hundred? At such volumes, 3d printing makes much more sense.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Savegame drive idea

Post by TmEE co.(TM) » Mon Mar 21, 2016 12:09 pm

You'd need moulds for the controller port dongle, there's no winning on that regard, and you need your own cart moulds anyway unless you're happy with the existing stuff. I imagine you can just use everdrive shells, those should be around for grabs also. 3D printing is viable option also.

Only real concern is the file system stuff but it is write once business anyway, after that everything can reuse the code.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

bastien
Very interested
Posts: 208
Joined: Mon Jun 25, 2007 7:19 pm
Location: Besançon,France
Contact:

Re: Savegame drive idea

Post by bastien » Tue Mar 22, 2016 7:10 am

TmEE co.(TM) wrote:SD card slot on the cart is way cheaper than any dongle you can attach to the controller port. You don't need almost any logic to read and write the SD card, there's no strict timing requirements so you can bitbang all you want, no need for any CPLDs and FPGAs with serializer/deserializer and whatnot.
Hi,
Just a question, for a Genesis, what cartridge pin did you use for spi bit banging ?

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Savegame drive idea

Post by TmEE co.(TM) » Tue Mar 22, 2016 8:11 am

!TIME as access strobe for the buffer/flipflop and those attached to the databus. Writes control DI and Clk and CE, reads return DO. It can be done with like 3x 74 logic chips.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

bastien
Very interested
Posts: 208
Joined: Mon Jun 25, 2007 7:19 pm
Location: Besançon,France
Contact:

Re: Savegame drive idea

Post by bastien » Tue Mar 22, 2016 12:02 pm

Thanks for this tricks.
Must find some Time for try.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Savegame drive idea

Post by Sik » Wed Mar 23, 2016 12:41 am

Decided to take some measurements to see how fast the 68000 can bitbang a port (not any interface in particular, it's just to get an idea):

Code: Select all

; d0 = clock high (e.g. $02)
; d1 = clock low (e.g. $00)
; d2 = gets the data bit
; d3 = mask for data bit (i.e. $01)
; d4 = byte being read
; a0 = hardware port

    move.b  d0, (a0)        ; 8 cycles
    move.b  (a0), d2        ; 8 cycles
    move.b  d1, (a0)        ; 8 cycles
    and.b   d3, d2          ; 4 cycles
    add.b   d4, d4          ; 4 cycles
    or.b    d2, d4          ; 4 cycles
                            ;------------
                            ; 36 cycles per bit

; a1 = buffer in RAM
; d5 = bytes left to read

    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    @BitBangMacro           ; 36 cycles
    move.b  d4, (a1)+       ; 8 cycles
    dbf     d5, @loop       ; 10 cycles
                            ;------------
                            ; 306 cycles per byte

262 lines per frame * 488 cycles per line = 127856 cycles per frame
127856  cycles per frame * 60 frames per second = 7671360 cycles per second
7671360 cycles per second / 306 cycles per byte = ~25069.8 bytes per second

~25069.8 bytes = ~24.48 kilobytes
Now, this is optimistic and I know I just approximated the 7.67MHz clock (and also ignores RAM refresh delays and IRQs), but I guess it should give a good estimate. Somewhere around the 20KB/s ballpark doesn't sound that unreasonable.
Sik is pronounced as "seek", not as "sick".

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: Savegame drive idea

Post by doragasu » Tue Jul 26, 2016 6:54 am

Sik wrote:Also one of the reasons I want to avoid SD cards is that then you'll be expected to cope with the FAT32 format (or worse, ExFAT), which makes things significantly more complex compared to a custom simpler filesystem.
Not really. You can read and write sectors directly without using a filesystem. Not the most interesting way of using an SD card, but definitely an option. And has the advantage that if today you are OK using raw sector reads/writes but tomorrow someone wants to port FatFS (or any other FAT library) to stream large chuncks of data into a game/music/video player, they need no new hardware design.

If I was doing it, i would definitely go for the SD card approach. Cheap (we all have SD cards lying around, so you only need the slot and a bunch of passives), high capacity, future-proof and readable by any PC without requiring an Everdrive or any strange hardware adapters.

BTW to do the level shifting, maybe just a bunch of resistors will work (wire MISO directly to the port, and the other pins through resistor divider networks), since you will not be shifting bits at very high speeds. I used this approach when I built my RGB Uzebox (using a 5V microcontroller to read the SD card) and it worked perfect. You will need a 3.3V LDO though, but they are also cheap.

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Savegame drive idea

Post by HardWareMan » Tue Jul 26, 2016 1:29 pm

Earlier, I showed this EXT adapter. With hardware SPI interface inside CPLD I achieve almost speed of 21 KBytes/s raw sector reading (SPI @~5MBps). With bitbang you'll get much less.
Image

Post Reply