|
Post by cbmguy on May 26, 2015 20:12:32 GMT
Thanks for the info. It was that C=Key, indeed. Once the classes are finished I might have some time to glue all the parts together--I might be able to find a ps/2 keyboard, as well. But until then, I plan on getting the keyrah v2 to work with all the keys on the c128 regardless if is kills me in the process lol. I can share the vice keyboard definition file that I wrote if you want it.
Cheers, c
|
|
|
Post by cbmguy on May 25, 2015 17:30:42 GMT
Hi, I have a bare 128 keyboard that I have interfaced with a keyrah v2 to use with the X128 Winvice. After a little tweaking I have all the keys on the c128 functioning as they are intended to be on the real thing (crsr keys work as well as the two crsr key with shift working, number pad is proper, etc.). However, I'm stuck on a group of keys that refuse to be separately map-able. The help, line feed, 40/80 column and no scroll bank of keys seem to reply with the function keys definitions--or vice versa depending on the mapping. It's very frustrating. I've looked high and low for an example, a reason, a suggestion, etc. but I've come up empty. Does anyone have any experience with this? As a common thread, but a separate question; I remember purchasing a kit from Brian's retro store for a keyboard hookup but have yet to glue it all together. Would that work better, if you would know? I can't remember--is is USB or strictly PS2? Thanks for reading c
|
|
|
Post by cbmguy on May 22, 2015 18:22:07 GMT
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)
|
|
|
Post by cbmguy on May 19, 2015 13:29:59 GMT
; 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
writeProtectCheck: print#15,"m-r";chr$(0)chr$(28)chr$(1):get#15,a$:a = asc(a$)and16 return
Hope this helps. Still not fool proof... It never will be unless you access the drive and check the error channel or disk ID or whatever, but this does remove the user tapping a key, etc.
|
|
|
Post by cbmguy on May 14, 2015 18:16:31 GMT
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.
|
|
|
Post by cbmguy on May 5, 2015 20:31:25 GMT
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 ;
|
|
|
Post by cbmguy on Apr 25, 2015 16:15:43 GMT
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. C oincidence 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...
|
|
|
Post by cbmguy on Apr 24, 2015 4:51:00 GMT
My goodness, wouldn't that suck if it was hey! lol but yes... I tried that. Cheers
|
|
|
Post by cbmguy on Apr 23, 2015 17:48:45 GMT
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.
|
|
|
Post by cbmguy on Mar 4, 2015 19:54:50 GMT
lol why is it in the comedy category? Looking good though. I can't wait to use it! Attachments:
|
|