CF Card formatting

[Michelle Lawson]

As I continue testing my Pro system, I have cobbled together some test boards and some standalone test software. In my testing of the CF card format capability, I have a couple of questions; a) how long does it typically take to format a 64MB card, and b) should the activity LED on the board have some indication of activity?

This is my test environment....
1. using the CF Card board as supplied & configured....
2. /CS0 test point shows good pulses as expected
3. no activity LED indication
4. have an 8 bit status indicator at port FFh that displays a count each time the cfWait and writeDir routines are completed
5. CF card is Cisco 64MB so using Grant's form64.asm code
6. Grant's code has only been modified to support the 85C30 serial IO in my system
7. code was added to the test code I am running standalone in my Pro system which uses 85C30 serial and not the SIO/2
8. test code is successful in serial port operation and RAM/ROM operation

9. top image is the console display indicating that my test code is capable of entering Grant's CF format routine and the bottom image is the CS0 test point on the CF card

[Mark Durham]

Michelle,

It's been a while since I played with my z80 system, but from memory formatting using Grant Searles code was pretty quick. From memory the formatting simply wrote an empty directory block to the start of each "disk" on the CF card.

As for timing, somewhere around the 10-30sec mark for my 128MB. From memory I would say that it was less than 60sec.

The activity LED on the CF to IDE adapter board illuminated during accesses.

Hope that helps.

Mark.

[Michelle Lawson]

Thanks for your reply Mark. That said, since there is no activity light blinking and it is taking way longer than a minute, I'm thinking there is an error somewhere in the code I grabbed from Grant's routine..... Hmmmmm

I attached the code if anyone is interested in commenting. Thanks

[Michelle Lawson]

Bug Report: #ID10T
Title: Unable to temp store a variable in write protected memory

Cause: Reusing, and embedding, Grant Searles form64.asm code into code that is resident in write protected memory means that temporary storage of the secNo and drvName variables are always FFh. The NOOB programmer (me) has since corrected this affront to all that is sacred in the programming world, and has made amends....

PS. I figured, if I looked at it long enough, the old bulb in my head just might go off...... Now, on to the next problem......

[Ed Silky]

Very Good!!!

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/89d3444f-3e94-4659-8730-2397d51ea27fn%40googlegroups.com.