Writing binary data to disk.

[eslapion]

Only if I had JSR'd to CLRCHN.

You use the RTS at the end of CLRCHN to return directly to basic!

Nice!

[eslapion]

@Mike
Your little routine gave a stunning boost to my device dumper.

Saving 16k is done in 4 seconds when JiffyDOS is activted!

That's a whopping 4 kBytes per second!

Impressive!

[eslapion]

I just performed my first complete 256k dump. It took 76 seconds - an average of 3440 bytes/second.

A single file of 262144 bytes was generated - exactly what I need.

First time I see a 1033 blocks file in a 1581 directory without an error causing it!

Kewl!

[Mike]

First time I see a 1033 blocks file in a 1581 directory without an error causing it!

orion70 and I used CBM files with a four digit number of blocks, with partitions, to hold the text body of the two instances of our Bible Series (#1: The 4 Gospels, Acts of the Apostels and Revelation, and #2: Pentateuch).

[orion70]

But THAT was a miracle

[eslapion]

@Mike
Would you care to suggest a "verification" routine?

(compare content of a file with the content of the 256kB device attached)

If possible, I would want the software to aks me how many errors are required to stop and of course, to list these errors and provide the address at which they occured.

I noticed my EPROM programmer, after programming a chip, will verify the content at Vcc +10% and then Vcc -10%. While its quite difficult to do +10%, -10% appears more important. Its quite easy to mod my already modded Behr-Bonz to feed 4.5 volts instead of 5 volts to the D.U.T.

[eslapion]

From another thread...

What is done in the subroutine at line 100?

You didn't need this information! At that point it was clear to me that I had a routine which read the bytes from the dumped device one at a time and copied it in RAM and THEN I wanted to dump the RAM section. However, the device reader routine which you demanded wasn't complete because the hardware itself was still a work in progress.

Instead of providing me with a simple routine to quickly dump a memory area, you started to ask useless questions about how the registers to access the device being dumped worked so I tried another method and changed the hardware. Instead of helping, you stumbled in the flowers in the carpet.

You blame me for trying to adapt to what you did - I couldn't provide you with the details you demanded on the device reader so I made another. The modded Behr-Bonz cart was the quickest way to change direction and have a working hardware reader so I could give YOU an answer. It was a LOT of work and you seem not to have the slightest care for it.

what could you have possibly done with the device reader registers ?? You didn't need this information AT ALL!

I changed the device reader to a modded Behr-Bonz to make it easier FOR YOU. I trashed the original reader FOR YOU!

Now you say you won't help me because I did exactly what you asked for???

I still desperately need this verification routine.

Originally, all I wanted was a piece of code to quickly save a memory area to a SEQ file. What could it possibly matter to you how the data in this area was placed there?

it *was* necessary to get some information from you while you went to change the hardware register setup *three times in a row*, and then you continued with an extra inquiry about a verifying routine. No thanks.

I guess it's my fault really. I should NEVER have placed myself in a situation of dependency to someone who expresses such boundless contempt towards my efforts to meet their requirements.

[eslapion]

I have modded the dumper routine to read 256k from a SEQ file and put it in a hypothetical RAM accessed in the same manner as the device to dump.

Basic portion becomes:

Code: Select all

14 OPEN2,11,2,"READ.BIN,S,R"
15 FORT=0TO15:POKE38912,T:SYS673,2:NEXT
16 CLOSE2

ML portion becomes:

Code: Select all

.02A1             20 F1 D7  JSR $D7F1   ; read channel number from BASIC text into X
.02A4             20 C6 FF  JSR $FFC6   ; CHKIN - set channel in X for input
.02A7             A9 00     LDA #$00
.02A9             85 FB     STA $FB
.02AB             A8        TAY
.02AC             A9 40     LDA #$40
.02AE             85 FC     STA $FC     ; set high byte of pointer to $40
.02B0             AA        TAX         ; ... incidentally also number of pages to read
.02B1  +---+--->  8A        TXA         ; put current X and Y on stack
.02B2  |   |      48        PHA
.02B3  |   |      98        TYA
.02B4  |   |      48        PHA
.02B5  |   |      20 CF FF  JSR $FFCF   ; CHRIN from file
.02B8  |   |      91 FB     STA ($FB),Y ; write byte to RAM
.02BA  |   |      68        PLA         ; restore X and Y from stack
.02BB  |   |      A8        TAY
.02BC  |   |      68        PLA
.02BD  |   |      AA        TAX
.02BE  |   |      C8        INY         ; increment effective address within page
.02BF  |   +---<  D0 F0     BNE $02B1
.02C1  |          E6 FC     INC $FC     ; increment high byte of pointer
.02C3  |          CA        DEX         ; decrement remaining pages
.02C4  +-------<  D0 EB     BNE $02B1   ; until =0.
.02C6             4C CC FF  JMP $FFCC   ; CLRCHN - restore default output

I guess I become more productive when I am pissed out of my mind...

Now I am not done with the verification program but somehow I suspect it involves opcode $D1

[eslapion]

Verification routine latest result:

BASIC:

Code: Select all

14 OPEN2,11,2,"PROPER.BIN,S,R"
15 FORT=0TO15:POKE38912,T:SYS673,2
16 IF PEEK(251)>0 THEN PRINT"FAIL AT BLOCK ";T:END
17 NEXT
18 CLOSE2

ML

Code: Select all

.02A1             20 F1 D7  JSR $D7F1   ; read channel number from BASIC text into X
.02A4             20 C6 FF  JSR $FFC6   ; CHKIN - set channel in X for input
.02A7             A9 00     LDA #$00
.02A9             85 FB     STA $FB
.02AB             A8        TAY
.02AC             A9 40     LDA #$40
.02AE             85 FC     STA $FC     ; set high byte of pointer to $40
.02B0             AA        TAX         ; ... incidentally also number of pages to read
.02B1  +---+--->  8A        TXA         ; put current X and Y on stack
.02B2  |   |      48        PHA
.02B3  |   |      98        TYA
.02B4  |   |      48        PHA
.02B5  |   |      20 CF FF  JSR $FFCF   ; CHRIN from file
.02B8  |   |      D1 FB     CMP ($FB),Y ; compare ACC with RAM
.02BA  |   |      D0 0F     BNE $02CB   ; Go to FAIL condition
.02BC  |   |      68        PLA         ; restore X and Y from stack
.02BD  |   |      A8        TAY
.02BE  |   |      68        PLA
.02BF  |   |      AA        TAX
.02C0  |   |      C8        INY         ; increment effective address within page
.02C1  |   +---<  D0 EE     BNE $02B1
.02C3  |          E6 FC     INC $FC     ; increment high byte of pointer
.02C5  |          CA        DEX         ; decrement remaining pages
.02C6  +-------<  D0 E9     BNE $02B1   ; until =0.
.02C8             4C CC FF  JMP $FFCC   ; CLRCHN - restore default output
.02CB             68        PLA
.02CC             68        PLA         ; restore stack to previous condition
.02CD             A9 FF     LDA #$FF
.02CF             85 FB     STA $FB     ; flag error code for BASIC
.02D1             4C CC FF  JMP $FFCC   ; CLRCHN - restore default output

Added edit:
2 PLA op added ad $02CB-$02CC

[eslapion]

Reader routine tested and working...

[Mike]

When a comparison fails, X and Y are still stacked and the routine will crash.

[eslapion]

When a comparison fails, X and Y are still stacked and the routine will crash.

This is exactly what happened during the tests.

I inserted a pair of PLAs.

1. Thank you for your comment

2. When the VIC crashed there were no error messages at all - it completely froze. RUN STOP/RESTORE didn't work and the drive kept on spinning.

3. I checked the verification routine using a Scott Adams game cartridge - it works now.

[TNT]

Why push/pop Y at all if your code already relies on it to not to change in CHRIN? Also, while Programmer's reference guide says that X is affected, the example given there uses X as index, implying that you don't need to push/pop it either. At least for IEC bus that's safe.

[Mike]

Why push/pop Y at all if your code already relies on it to not to change in CHRIN?

I agree pushing Y is redundant. In my defence, it is a snippet reused from old code. Better safe than sorry.

Also, while Programmer's reference guide says that X is affected, the example given there uses X as index, implying that you don't need to push/pop it either.

That's the rub. Tape use for CHRIN happens to affect the X register (and I fell over this in one application indeed), but ...

At least for IEC bus that's safe.

... you really don't want to read that huge amount of data from tape, indeed.

2. When the VIC crashed there were no error messages at all - it completely froze. RUN STOP/RESTORE didn't work and the drive kept on spinning.

That depended on what was in X and Y at the time they were pushed, and what was in RAM at the place of the wrongly assumed return address. Could be anything from a collection of (illegal) opcodes leading to a BRK and causing a BASIC warmstart (as if STOP/RESTORE had been pressed); or that chain of instructions ending up at an opcode ending in $x2 other than $A2 (LDX #imm) or $82, $C2, $E2 ("illegal" NOPs), which cause the state machine of the 6502 to lock up. In the latter case, only a reset revives the CPU.

(P.S. on the keys labeled "CLR HOME", "INST DEL" and "RUN STOP", the three captions HOME, DEL and STOP denote the unshifted action, and CLR, INST and RUN denote the shifted action - RUN meaning "load and RUN the first program from standard mass storage". )

[eslapion]

... you really don't want to read that huge amount of data from tape, indeed.

The applications discussed in this thread can save, load and verify data in amounts ranging from 16k up to 512k. Definitely, this is not for tape.

I use JiffyDOS on the VIC-20 along with a 1581 also equipped with JiffyDOS and the resulting transfer speed is about 3.5kB/s.

I guess it would be possible to use SD2IEC too.