Page 2 of 2
Re: Savegame drive idea
Posted: Mon Mar 21, 2016 12:52 am
by Sik
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...
Re: Savegame drive idea
Posted: Mon Mar 21, 2016 9:41 am
by cero
Why bother with a mold (~10k) when the userbase is likely just a few hundred? At such volumes, 3d printing makes much more sense.
Re: Savegame drive idea
Posted: Mon Mar 21, 2016 12:09 pm
by TmEE co.(TM)
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.
Re: Savegame drive idea
Posted: Tue Mar 22, 2016 7:10 am
by bastien
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 ?
Re: Savegame drive idea
Posted: Tue Mar 22, 2016 8:11 am
by TmEE co.(TM)
!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.
Re: Savegame drive idea
Posted: Tue Mar 22, 2016 12:02 pm
by bastien
Thanks for this tricks.
Must find some Time for try.
Re: Savegame drive idea
Posted: Wed Mar 23, 2016 12:41 am
by Sik
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.
Re: Savegame drive idea
Posted: Tue Jul 26, 2016 6:54 am
by doragasu
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.
Re: Savegame drive idea
Posted: Tue Jul 26, 2016 1:29 pm
by HardWareMan
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.
