Hi guys,

I've had my favourite hobby projects sitting on my shelf right next to my office desk for years thinking that someday..... Well that day never seem to come along, so rather than havig my gems rust and rot away, I am selling some of them for someone else to enjoy. They are all basically 6502 based designs that I have done either myself or purchased systems. I'll provide all the hardware, software, documentation and personal assistance anyone needs to get them up and running

Here's the first one to go: http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 1283413699

Have nice day everyone
/Pontus

Very nice. What are the trimmers for (two variable resistors and a variable capacitor)?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

How is the Flash ROM programmed? Is that done on board, or does it need to be removed first?

Why did you choose 32K of ROM? That seems like a lot. Will it support 2 drives with the normal floppy cable?

BDD: He has a TMS2793 FDC on there. Not sure if that's in the post or the ebay listing.

This is the kind of machine I visualized building back in the day. But I didn't know what to do about an FDC.

I have 32KB of ROM because my very full-featured Forth takes something like 2/3 of it, and makes my applications in RAM much smaller and easier to develop since so much is already done. The only thing I would want more RAM for is large arrays of data.


Today it seems like SD card would be the way to go; but I recently looked into it, and there are different block sizes, security issues (hence the name "Secure Digital"), two different CRC error-detection schemes, different densities, and different file systems used, and I find it daunting! Does anyone know an "SD-Card Guide for Dummies"? I've used tiny serial flash memories and you can of course do the file system any way you like, but then it won't let you exchange files with a PC. With floppies, you could probaly stay with only 1.44MB and FAT16 and be done with it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've worked with SD cards, and some things are simpler in SPI mode. The CRC is optional, for instance, although I've noticed that some cards require CRC7 on the commands, so I've added that. There is no security in SPI mode. Blocks default to 512 bytes, and I never change them. I don't worry about the density of the card, or any other properties. After init (which is a bit tricky), it's just a big array of 512-byte blocks.

Filesystems used on the card are FAT16 or FAT32, and it's a good idea to leave the manufacturer's formatting on the card. You need to be able to deal with a single filesystem, or partition table in the boot sector.

I did plan to use SPI, and I would like to find it's all much easier than the Wikipedia article and a Maxim ap. note make it out to be; but Wikipedia says for example that the formats could be FAT12, FAT16, FAT16B, FAT32, FAT32X, NTFS, exFAT, HFS Plus, UFS, Ext2, Ext3, Ext4, btrfs, HFS Plus, or ReiserFS, and the partition types could be of several different types also. We would probably have to be able to handle all of them for our customers with different ages of cards and of computers with Windows, Mac, and Linux. For what I wanted, the teensy risk of errors, multiplied by the near-insignificance of losing a random byte somewhere, would mean that going without CRC would be fine for our application. Any links you can give to get a handle on it would be appreciated. Up to now it looked like I would have to drop the idea.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's probably best to open a new thread for this...

I think it's safe to assume the filesystem is FAT16 or FAT32. Cards are preformatted by the manufacturers, and they always use FAT (small cards use FAT16, big ones use FAT32). Also, the card controller and the actual flash hardware is optimized for FAT access patterns, both for speed and wear, so that's why it's a good idea to leave it formatted as it is.

I've put some documentation I've collected on my site: http://ladybug.xs4all.nl/arlet/sdcard/

I've had several run-ins with SD cards in the past... I am putting together an SD interface for the CHOCHI/DILDAR boards and will report when I have some results.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I designed and built a FDC controller to handle 4 drives with either single or double density back in the 80's based on a WD2797 (TMS2793 is a variant of this chip) and wrote a pretty full BIOS for it and had it running as a plug-in card for a Vic-20. The variable cap is to trim the VCO center frequency, one trimpot is for setting the write precomp width and the other is for read pulse width on the data comparator. The WD1792/3 used the in the 1581 had much of this stuff built in and didn't require as much external circuitry. I still have the BIOS source code kicking about.... and used the set overflow pin on the 6502 for the DRQ (data request) line which allowed the slow CPU clock on the Vic to be able to keep up with the data transfers. My expansion board (which the FDC plugged into) for the Vic contained a full 6551 async port, a realtime clock, 1KB RAM (two 2114 chips) using one of the 1KB I/O selects (used as sector buffers for the FDC and xmit/rcv buffers on the 6551) plus an 8KB RAM or ROM to hold additional BIOS code for the hardware, and a 74LS138 for I/O decoding of the second 1KB I/O select. I had it all working at one point... could even run the 6551 at 19200 in loopback mode without errors.

_________________
Regards, KM
https://github.com/floobydust