6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Sep 21, 2024 3:11 am

All times are UTC




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Problems with CRC-16
PostPosted: Mon Mar 04, 2019 10:55 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1467
Location: Scotland
whartung wrote:
drogon wrote:
I know :-( It's a bit ridiculous, but I really didn't want to go to floppys or my little retro project, much as I love my 40 year old Apple II ones that still work.. So I'm sort of pretending an SD card is a floppy - after all, it's about the same flexibility as a 3.5" disk is... ;-)

I know what you're talking about. All that "wasted space".

For a Forth standpoint, a 16 bit Forth that is, 65MB is the peak, since you can only have 65,000 "screens" (which are 1K each).

When I think about 65,000 screens - man, that's a lot. On the other, it's a lot of wasted space (screens are simple, not efficient :) ).

But the key point, to me, when thinking about this stuff, and off putting to me, was that, yea, using an SD Card as a floppy (or, pretty much anything), is all well and good, but what you (I) really want is the ability to copy data off of the system. For that, you need TWO "floppies".


I have put some thought into this...

Sp plan A: Serial cable and time. (Kermit, is that you?)

Or just pop the SD card out, pop it into a handy Linux box (either one with SD card reader built in, or a USB one), FUSE mount the filesystem and off you go. Another reason I'm writing my filesystem stuff in C - just need to learn how FUSE works now...

However as I have a spare pin on my ATmega, then a 2nd SD card adapter might not be out of the question... (although I plan a 3>8 '138 type chip to give me 8 SPI channels in the next revision, so many...)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
 Post subject: Re: Problems with CRC-16
PostPosted: Tue Mar 05, 2019 12:58 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
drogon wrote:

I have put some thought into this...

Sp plan A: Serial cable and time. (Kermit, is that you?)

Sure, at least you have time to get a sandwich :).

Quote:
Or just pop the SD card out, pop it into a handy Linux box (either one with SD card reader built in, or a USB one), FUSE mount the filesystem and off you go. Another reason I'm writing my filesystem stuff in C - just need to learn how FUSE works now...

Of course.
Quote:
However as I have a spare pin on my ATmega, then a 2nd SD card adapter might not be out of the question... (although I plan a 3>8 '138 type chip to give me 8 SPI channels in the next revision, so many...)

My nit about this is Yet More hardware I have to mount to a board, and -- I'm just not good at it. So, that's just me. USB I get hubs "for free".

My meta goal is to make such a system as stand alone as practical. In the Sleep Beauty Castle version, it's stand alone and self hosting. Can build it's own software on the system. The P-System is (was) self hosting. It could build it's own runtime. The "fast" way to do that is to get a "Forth in Forth" built on it and come up with a tool chain to build new Forth boot images on it. Using a board programmable Flash ROM let you take it all the way.


Top
 Profile  
Reply with quote  
 Post subject: Re: Problems with CRC-16
PostPosted: Tue Mar 05, 2019 9:46 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1467
Location: Scotland
whartung wrote:
My nit about this is Yet More hardware I have to mount to a board, and -- I'm just not good at it. So, that's just me. USB I get hubs "for free".


If only USB was easy to interface to an 8-bit system. It's hard enough that you might as well just stick a Pi on it and be done )-: Even the ATmega 'u' series which have native USB are tricky to get much more than basic HID (keyboard/mouse) via their USB interface - however just been doing some searching and the MAX3241E device looks like an SPI addressable USB host controller. I think you might still need a shed-load of code on the 6502 side to drive it to even get to the block-level of (say) a USB drive though.

whartung wrote:
My meta goal is to make such a system as stand alone as practical. In the Sleep Beauty Castle version, it's stand alone and self hosting. Can build it's own software on the system. The P-System is (was) self hosting. It could build it's own runtime. The "fast" way to do that is to get a "Forth in Forth" built on it and come up with a tool chain to build new Forth boot images on it. Using a board programmable Flash ROM let you take it all the way.


Self-hosting is my goal too. We used to do it - e.g. the Apple II had a C compiler (Aztec), Forths, Logo and many assemblers. The BBC Micro had dozens of "languages" from Basic to Pascal, BCPL, Forth, Comal, Logo, Lisp and who knows what else. I doubt I'll ever get a C compiler to work on my system but I already have most BBC Micro ROMs working which was never my intention, but it just sort of happened that way...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
 Post subject: Re: Problems with CRC-16
PostPosted: Tue Mar 05, 2019 6:10 pm 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
drogon wrote:
I have the luxury of coding all mine in C on an ATmega that's the host to my 6502 system. Currently running the SPI clock at 8Mhz and using one of the sparkfun level shifter boards - 8Mhz is the max. possible on a 16Mhz ATmega. (after running it at 400Khz during initialisation) I've no plans to turn data CRCs on if I can possibly avoid it...

What sort of filing system are you looking at? I'm writing one loosely based on ProDOS8... So max. 32MB 'disk' but it reads a standard MBR, so 4 disks of 32MB each is possible - for now.

(currently have an 8GB microSD plugged in - all that space ... ah well!)

Cheers,

-Gordon


Well, with some troubles I got CRC7 working. So all commands are now sent with a CRC7 checksum. The CRC16 is still not reported correctly.. or calculated in a different way... but things seems to be more stable with the CRC7.

My solution is based on a small FPGA with my own SPI implementation (using a 1KiB DMA buffer), thus I can run it as fast as I need. The filesystem is FAT32 for simple file transfer (based on SteckOS, but heavily modified). It is still not finished, but I have long filenames working (don't ask how..).

The SD Card is a 8GiB SDHC card (class 4), so I only implemented support for that. I would have liked to have a smaller card (they initialize faster), but they seems to be more expensive.

Edit:
Using this page: http://www.tahapaksu.com/crc/ I was actually able to calculate the CRC from the first directory block. The CRC-CCITT (0xFFFF) value I get in this page is the same that the 6502 program calculates, but the one reported by the card is the same as the CRC-CCITT (XModem).. Pretty annoying since I have read several times that $ffff is the correct seed for an SD Card. :? Anyway, its working now.

Thank you all for all the help!


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

All times are UTC


Who is online

Users browsing this forum: Dr Jefyll and 23 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: