lol so sorry. I knew the answer and got excited--I was just working on that solution just the day before. That routine is used with the burst protocol which isn't presented in that snippet--when data is entering, I count it (y register) and then I stash the byte away using the stashbyte rountine. In my case, I stash the byte in bank 0 and then continue on with the burst data stream and y is the offset. You can change the value of the x register to Bank 1 ram using the appropriate byte for the mmu--I don't know those just off the top of my head atm. p2 refers to a zero page indirect pointer (incremented each time y rolls to 0). To get the byte, it's the same thing, but one is loading the register with the data and the stream of data is being sent to the drive. All performed sequentially--it works for all file types (except maybe rel)
; Check for the write protect byte/nibble in drive to monitor disk swap ;
print" please change disks." open 15,8,15 : gosub writeProtectCheck: if a<>0 then :- ; rem wait for disk to be removed : gosub writeProtectCheck: if a<>16 then :- ; rem wait for no disk in drive : gosub writeProtectCheck: if a<>0 then :- ; rem wait for disk to be inserted for d = "I to 1500: next: close 15 print "ok, thanks!" end
It is possible to check if there is a disk in the drive by monitoring a memory location in the said drive (I cannot remember the exact location ATM). It is impossible to monitor the drive door in such a way, however. Assuming that you want to automate things somewhat in your program for the disk swapping and such: IMHO, since you can tell that there is a disk inserted or not, it would best to approach it like so: monitor the location for a disk inserted, loop back and wait if it's not. When true, wait a second or two to allow the user to close the drive door, then read from the drive. If it errors, ask the user a question: Did you close the drive door? Format disk? or go back to monitoring the disk insert and do it again until there is no error (which might end up looping infinitely), and then when everything is right (drive in and door shut) go on about the action with that returned event. I'll post the drive locations when I get home later in the day.
Here's a snippet from my file/drive management source code I'm writing. Cheers, c
; stashbyte =* ; save a byte in bank 0 ldx #$3f stx mmu ; go to bank 0 sta (p2),y ; save data ldx #0 stx mmu ; back to default bank rts ; and return ; getbyte =* ; get a byte from bank 0 ldx #$3f stx mmu ; go to bank 0 lda (p2),y ; get data ldx #0 stx mmu ; back to default bank rts ; and return ;
Considering everything that has been replaced before it, it that question that has to be asked lol Thank goodness I plugged it in lol. But the one thing here is this: The unit has always had this problem since I've had it (about 5 yrs now). As I was replacing things, I used sockets for the replacement chips. Last month decided I would give it another go now that teaching is in its groove and the students are in their projects thus I have a bit more time. Happen-chance I moved the old PLA just a bit and it worked for about a week. I was playing games I had on disk and everything. Then, a few days later, it was back to the weird colour thing again and it's never recovered. Coincidence perhaps. Resoldering the PLA socket didn't change things--in our out of the chassis the 40col still remains the same.
Not likely we would find a magic cable that drains the chroma AND luminance out of every other character... at first I thought it resembled bad combining of luma and chroma into the video input, but those black letters...
I bought a C128Dcr a few years ago and I now have the time to put into it, so I'm back at it. It has a strange problem with colour on the VIC side & it happens for both 64 mode and 128 mode. The colours for the characters are almost always black & grey--alternating between the two. Every once and a while a letter will display in a colour, but not the proper colour. In the images, the V on the C64 and the S in the C128 are coloured... it's wierd. The border and background are perfectly fine. None of the characters are messed up, just the colour. Changing colours only changes from/to black or gray.
I was checking things over a few weeks ago and at one time, for a few days, everything was back to normal. But since then, the weird came back. I've changed the 4066 timer and the colour RAM--no difference. I just recently changed the PLA, no difference. I changed the VIC II and the 8701 and the crystal, no difference. I bought a new power supply, no difference. All new parts are in it, but there is no difference. Am I missing something? Could it be a cap? If so, which one might be the best guess to change? Could it be something in the RF?
This is just the VIC side, everything else works fine--sid, vdc, etc. It's driving me insane and I can't put this puzzle down lol They are so hard to come by now a days that I would very much like to see my dcr back and working well. It's really the only reliable 1571 that I have, too.
I think I might have found one in Toronto...I think. The cost is $50 CDN and the shipping is only $12. The ebay price looks very reasonable, all considering. But shipping it to me is almost the same cost as the part, making it about twice as much lol. Can't win for losing. Thanks for the info