Chuck(G)
25k Member
I suppose, but c'mon--I shouldn't have to guess at the meaning of an expression!
Humpty Dumpty said:
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Wishlist XT Peripherals
- Thread starter Crypticalcode0
- Start date
I suppose, but c'mon--I shouldn't have to guess at the meaning of an expression!
Crypticalcode0
Experienced Member
@Chuck well i am nearly sure it could not be that.
CAV is default for a FDD only deviant i know of is the Commodore 1541 FDD but that is a micro system in it's own right.
Would Zone Constant Angle Velocity have any advantage?
CAV is default for a FDD only deviant i know of is the Commodore 1541 FDD but that is a micro system in it's own right.
Would Zone Constant Angle Velocity have any advantage?
vwestlife
Veteran Member
The 1000RL already has a built-in IDE-XT hard drive interface (Tandy calls it "SmartDrive"), which I use with a ST-351A/X drive. I know there are ATA (IDE-AT) to CompactFlash adapters, so I'm just saying it would be nice to have an IDE-XT to CompactFlash adapter.
Chuck(G)
25k Member
You forgot Apple (Lisa and original Mac) as well as the Sirius/Victor 9000.
I didn't think the expression was that far off but probably so for those in the know. I meant having the motor stepping, c/h/l or c/s (suppose it's different than a hard drive) alignment be adjustable. Hence not stuck at 40/80 track spacing and could be told to read smaller track sizes with more intelligent macros/modules.
xtfdc type amiga dsdd read a:
xtfdc type cpm sssd scan a:
or the actual point
xtfdc fsscan a:
and have it try all the modules you have and see if it can come up with a recognized file format/fat table.
Pardon my ignorance on the technical specs, it's just how I guessed the catweasel worked.
xtfdc type amiga dsdd read a:
xtfdc type cpm sssd scan a:
or the actual point
xtfdc fsscan a:
and have it try all the modules you have and see if it can come up with a recognized file format/fat table.
Pardon my ignorance on the technical specs, it's just how I guessed the catweasel worked.
Chuck(G)
25k Member
The principle of operation of the catweasel is very simple. There's a free-running counter (speed selectable between roughly 7, 14, 28 and 56 MHz) and a block of SRAM (131K/128KiB and a counter for SRAM address control). Every time a pulse arrives from reading a floppy, the lower 7 bits of the counter are stored into the SRAM, the store address is incremented and the counter is reset. The high-order bit is connected to the index output, so you have an idea of whether or not you're within the index area when a sample is taken. A track is read (depending on program control, this can be index-to-index or when the SRAM is full) and then the PC reads the SRAM. There's a very basic set of latches that can control the density select, step and direction outputs, but the timing is done under program control for those--just a simple bit-bang affair.
It's up to the software to figure things out. Writing works in the opposite direction--the program stores the transition times to the SRAM and the counter is used to bang the write data line at the appropriate time.
Everything else is left to the program. This is the principle of operation of all of the other similar bits of kit, such as DeviceSide, Kyroflux, etc. They differ only in details.
Mind you, you can't simply copy a disk by feeding back what you read. There are various effects such as quantization error and bit-crowding (prcompensation) that need to be accommodated. A few years back, I posted a way to do this using a simple ATMega microcontroller-with-SRAM setup, where a 16MHz clock was more than sufficient to process 1.44MB floppies. Not a lot of interest, so I let it go without much other comment. Modern MCUs have sufficient SRAM to be able to do this all on one chip; not to mention built-in USB OTG facilities. So there's really not much in the way of hardware to do--just sharpen your coding pencil...
It's up to the software to figure things out. Writing works in the opposite direction--the program stores the transition times to the SRAM and the counter is used to bang the write data line at the appropriate time.
Everything else is left to the program. This is the principle of operation of all of the other similar bits of kit, such as DeviceSide, Kyroflux, etc. They differ only in details.
Mind you, you can't simply copy a disk by feeding back what you read. There are various effects such as quantization error and bit-crowding (prcompensation) that need to be accommodated. A few years back, I posted a way to do this using a simple ATMega microcontroller-with-SRAM setup, where a 16MHz clock was more than sufficient to process 1.44MB floppies. Not a lot of interest, so I let it go without much other comment. Modern MCUs have sufficient SRAM to be able to do this all on one chip; not to mention built-in USB OTG facilities. So there's really not much in the way of hardware to do--just sharpen your coding pencil...
FishFinger
Experienced Member
I made a CGA to Scart adaptor a few years ago, which works very well, although results can vary a bit from one TV to another. Not very useful for American TVs, but everywhere else should have Scart on any TV made after about 1990.
Chuck I think pondered on this a while back. The thing is, it would need a new PCB, new logic designed and somewhere to store the BIOS for it (since Compact Flash media must be told to switch to 8-bit transfer mode after power-up) - in other words, a load of development and testing.
On the other hand, the XT-CF board is approaching a beta phase (and I'm reasonably confident that it will also be faster, due to the transfer methods used).