So I built a joydrv_6551L.sb that saves the slot select, put it on the slot 0, does its thing and then restores the original slot # on exit. This read, according the <D.BtBug as 3 on the first boot attempt, but it still seems to do a puls pc,cc into never never land, except that about 10 minutes later, while I'm studying the listing, up popped a green screen with part of sysgo's output on it, but it then failed at the date t display.
On several reboots, including a powerdown reset for about 30 seconds, it is now displaying a '/' in place of the 3. To display a '/' there, with this code:
lda #'0
adda SlotSave, pcr
jsr <D.BtBug
it has to be reading $FF from SlotSave,pcr, which was originally written:
SlotSlct fcb MPISlot
SlotSave fcb MPISlot scratchpad space
[...]
lda >MPI.Slct which assembles as $B6FF7F
sta SlotSave,pcr
I just ran through the assembled defs 3 times without finding a location, hopefully in DP, that records the current MPI.Slot! From that I have to assume that $FF7F is both readable and writable.
So how do we keep track of it?
--
Cheers, Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>The size limit applies to 6809 boot files not 6309. It could well be a
>'new' bug but Boisy reminded me this was discussed previously in the
>defunct NitrOS-9 newsgroup/mailing list.
>I don't recall this existing in stock OS-9 Level2 or the original
>NitrOS-9 (Gale Force) versions. There were massive changes made to
>modules when Boisy decided there should be as much common source code as
>possible so Level1, Level2, Level3, and 6809/6309 could be generated
>from the same source code. This bug could easily have been introduced in
>this period.
>
>You can make finding the source of the memory limit bug your next
>project after you solve your joystick problem. :)
I think it also applies to 6309 machines as well. I put my bootlist on a diet
and got it down to a few bytes over 32k, and with a few caveats, it is working.
Sorta.
1. I have a scope on the mouses output, and I can see the blinking in the video
when I move the mouse, which tells me the IRQ line is being pulled down in
response to the mouse data coming in, and that the IRQ is being serviced
because the blinking is for as long as I'm moving the mouse, or pressing and
releasing a button on it. Before, it was never being initialized enough to
register and enable the chip to issue IRQ's, so this is progress. This is with
joydrv_6551L.sb set for a mouse address of $FF6C. Now, irqs says its there,
and at $FF6D.
2. On a reboot, back to this same disk, the boot will stall at about joydrv
init, and wait either for the rapture, or for me to move the mouse a fraction
of an inch. This says to me that the IRQ routine isn't being installed before
the chipset is properly init'ed and flushed of any pending data. Should we not
re-arrange that order somehow, but first disabling the chips ability to
generate an IRQ, then flush it, then install the IRQSvs, and then enable the
chip?
3. Multivue still cannot see the mouse, so I'm stuck with a useless multivue
screen I can't get rid of till a reboot is done. I looked at /dd/sys/env.file,
but that doesn't tell gshell where the mouse is & 15 years ago ISTR there was a
place/file that did tell gshell where it was.
Now, from reading the multivue book on mouse use, it reads like it shouldn't
really care what PTRSID is set to in the env.file as long as the joydrv
SS.Mouse call works. So I'm confused. Its currently, and was 15 years ago
when this all worked but before all this 'modularization', set to PTRSID=1.
What, if anything should it be set to now with this new joydrv thing? Back
then I *think* it was part of cc3io or??
--------------------
I also found what I'd sure call a bug in os9gen, it is treating an empty line in
bootlists/genes.bl as the eof, stopping the generation of the os9boot file at
that point, and w/o any reported error. I don't know when that crept into the
file, but I expect that has been part of my trouble every since the high window
descriptors were all found to be copies of each other. That really ought to be
fixed at some point so it doesn't bail out till it gets a real eof from the
filesystem.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
--------------
11:44 Saturday June 7th, 2008
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remember years ago when using OS-9 Level II that I had the same issue with joydrv for the 6551. Until I moved the mouse, OS-9 wouldn't fully come up. I don't have this setup any longer, so I cannot assist in debugging.
Some investigation will be required to understand why moving the mouse is necessary. I wonder where in the source that things could be "locked up" until the mouse moves.
As for os9gen, the behavior you described is not a bug. os9gen has always worked this way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gene, you have a point about joydrv_6551L.asm. Currently the init routine installs an IRQ before initializing the PIAs. That alone does not make sense. The order in init should be
suspend all interrupts
initialize PIAs, GIME, and MPI slot
send command (if there is one) to the 6551 to halt/reset
clear all flags
engage interrupts
It would be easy enough to relocate the OS9 F$IRQ to the end of the init routine. There is no equivalent to a 6551 Reset command in the code but if there is a Reset, it could be added.
Want to rewrite init and test it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The info in the RS-232 manual has a table indicating a write to $FF69 is a forced soft reset. Specifically, "A res* from the bus will clear all registers in the 6551, while a soft reset will only disable interrupts and transmitter, turn off the echo mode, and clear the overrun flag." Ambiguously, the manual also states, "The soft reset opertion clears the 6551 internal registers but does not cause any data transfer."
So, does a soft reset clear all registers or only a hardware res* ?
In either case, joydrv_6551L.asm does send a soft reset command to the 6551 in the init routine.
orcc #IntMasks disable IRQs while setting up hardware
sta PRstReg,x reset 6551
PRstReg is defined in l51.defs as $ff69 so the code is clearing the 6551 as best as is possible. The only problem, in my opinion, is the orcc comes too late in the routine, after the OS9 F$IRQ call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
suspend all interrupts
initialize PIAs, GIME, and MPI slot
send command (if there is one) to the 6551 to halt/reset
clear all flags
engage interrupts
That makes sense to me. At present, I am getting an "IRQ Storm" as soon as it has been init'ed. Also the scope says it is outputting a packet, maybe more, of data when the acia is enabled, which in turn powers up the mouse since it is powered from the acia lines.
As for this:
"PRstReg is defined in l51.defs as $ff69", note that is PRstReg,x and PRstReg is actually an offset of 1 and in this code x=$ff6C (I hope anyway) so that write would be correctly made to $FF6D.
However, even if I do move the mouse in time and it boots fully, multivue still can't find it. But I suspect that is a different beast entirely. :-) It does show up in the irqs report then, unlike the boot it is booted to now, where only the /t2 irq is showing. But that boot with a mouse will not format a floppy. This one will.
{t2|08}/DD/NITROS9/6309L2/MODULES/SCF:irqs
Polling Table at: 5DFB
Device Table at: 5C00
Device Driver IRQ Flip
Port Mem Name Vector &Mask Pty
---- ---- ------------ ----- ---
FF69 4C00 sc6551 E392 00 88 0A
Thanks for any more insight you can toss my way, I'm not exactly a 6551 guru. OTOH, I have found some nice info on this drain bamaged chip on the net, complete with workarounds for the ugliest bug related to CTS dropping in mid char.
One last thought, I've set the watch bit on this forum, which means I should be getting an email alert when a new post is made. I am not getting these, and someone please check why?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
In matters of principle, stand like a rock;
in matters of taste, swim with the current.
-- Thomas Jefferson
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've re-written it to do things in the order suggested by Robert. The reboot still hangs at i2xoXXX where X is a char I put in to indicate the execution of each of the 3 subroutines I made out of the individual pieces of code. I also commented out a boatload of code that was never called in the original version 6.
Now I push cc and disable the interrupts
Init the PIA's. GIME and MPI.slot (subroutine 'P')
reset the acia
clear the 8 byte wide buffer U points at
Init some of that buffer to starter values as before, but I'm not sure they are correct
read the chip to clear pending data as originally done, take exit if it won't clear on 2nd read as before
Install the svs routine with I$IRQ as before
enable the interrupts by pulling cc.
Now it will boot after outputting the tallies I put in the 3 subroutines I made of the above.
With these caveats of course:
at i2xoXXX, I have to move the mouse for it to proceed, but it then booted normally, initing all 4 screens I normally used and the shell on /t2.
However, the keyboard seems to be blocked until the mouse is moved, even just to service the clear key to switch screens! After quite a bit of that it seemed to get well and I could run utils from one of the screens. Multivue still can't find the mouse however, the pointer is stuck in the upper left corner.
The shell on /t2 I'm looking at here seems to be functional, a dir -e works, and an irqs shows:
{t2|08}/DD:irqs
Polling Table at: 6AFB
Device Table at: 6900
Device Driver IRQ Flip
Port Mem Name Vector &Mask Pty
---- ---- ------------ ----- ---
FF69 5300 sc6551 E3B7 00 88 0A
FF6D 10EC sc6551 B7E7 00 0F 01
Now, I'm about burned out for the day. I would like to put this code up so others can play & offer insight, or finish the fixing maybe, but my asking for instructions on how to use cvs to update a single, or maybe 2 or 3 files (joydrv_6551L.asm, dcheck.asm, and vtio.asm) in the repo have been ignored. I think now that there may be bogus control data being written either to PIA(0/1?), or to the 6551 itself.
I also added a counter output to the normal exit of the IRQSvs routine so I could see the byte count building up in buffer,u, but that is covered by the green screen in milliseconds after I move the mouse to generate that data. My persistence of vision isn't THAT good. :)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there are no substantive changes in scf.asm or krnp2.asm. Some tally outputs in the others added to trace things, and those can go as easily as they were added. joydrv_651L.asm is the biggie.
Does it ever tell me when its done?
I think I might have a handle on the irq lockup/storm, I believe the control register is getting set so an IRQ is generated for a TBE condition, which would always be true. I've downloaded the WDC version of the docs, 34 pages of dead tree now, and will see if I can get that sorted one way or the other.
But I am still not getting emails from srcforge when you all post replies. I did when I first signed up, but no more, and there is a checkmark beside the watch this on the forum's top page.
I did a forced exit, used a ! to reuse that log the next time, and then got informed I need write access to do that, bummer. So I suspect the repo is not touched.
--
Cheers, Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Robert went through the exercise recently of setting up his copy of the repository. You have CVS access to the project so you should be able to make commits IF you have checked out the repository as a user and not anonymously.
As far as monitoring the forum, I have this forum monitored and I get emails when you or anyone else posts here. I would check to see if your account has a current email on file.
Boisy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll do that. In the meantime this joydrv_6551L.asm seems to be set for some 5 byte packet protocol, and the logitek is a 3+1 protocol, the +1 (4th byte) being only for a middle button event. So that part of it is going to need a major rewrite as its expecting 5 bytes per packet.
In the meantime, the protocol says that on cycleing RTS, it will spit out the first of 2 ID bytes about 14ms later, followed by a second 'variation' byte about 63 milliseconds after that. I see 2, separated by about those times, bytes being sent by the mouse after the hardware reset and re-init I'm doing in this code ATM.
I've written it so that it should spit out those 2 bytes, they are supposed to be printable ascii bytes, to the screen during the init, then output a "S" to indicate its frozen there so I can read what it says between the i2xoPG and the S, but all I'm getting is i2xoPGS
Here is that code snippet from the listing:
00202 0086 AE8DFF81 ClrACIA ldx M$Mem,pcr get base h
00203 008A 4F clra
00204 008B 5F clrb
00205 008C ED02 std CmdReg,x do full hd
00206 * loads $0918, $09 to CmdReg=tx irq dis, no par, tx low
00207 * $18 to CtrlReg= 1200 baud 1 stop
00208 008E CC0918 ldd #(TIC.RTS!Cmd.DTR)*256+(DB.8!C
00209 0091 ED02 std CmdReg,x set comman
00210 0093 3420 pshs y
00211 0095 108E0000 ldy #$0000 long delay
00212 0099 313F NxtByte leay -1,y start cntr
00213 009B 2712 beq NxtBExit was InitEr
00214 009D A601 lda StatReg,x *Rx data,
00215 * this doesn't check TBE or IRQ
00216 009F A48DFF82 anda Pkt.Mask,pcr IRQ bits s
00217 00A3 27F4 beq NxtByte repeat 655
00218 00A5 9408 anda Stat.RxF got byte?
00219 00A7 27F0 beq NxtByte no, try ag
00220 * got a data byte, show it
00221 00A9 A684 lda DataReg,x get ID byt
00222 00AB 9D5E jsr <D.BtBug what was i
00223 00AD 20EA bra NxtByte there may
00224 * temp stopper
00225 00AF 3520 NxtBExit puls y fix stack
00226 * show we're stuck here
00227 00B1 8653 lda #'S
00228 00B3 9D5E jsr <D.BtBug
00229 00B5 20FE letmesee bra letmesee
00230 00B7 39 rts
If it was an M$ 3 button mouse, I should be seeing "i2xoPG'M3'S" there, so I'd assume for a logitek, it might be something like "i2xoPG'L3'S". But all I'm getting is "i2xoPGS", and the mouse is sending the 2 bytes of data, I can see it on the scope I have hooked up as it goes by. Obviously there is something wrong with my conditional branching above, but I can't see it.
One step at a time here, before I go charging off in all directions at once.
PktMask=$0F, and Stat.RxF=$08, correct according to the docs from WDC, who is making a cmos version of this chip. Nice docs too.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The curse of the Irish is not that they don't know the words to a song --
it's that they know them *___all*.
-- Susan Dooley
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gene,
It's hard to tell without seeing your complete code for the init routine but the snipit posted seems to be missing something. When you reset the 6551 you not only should read the status register but should also write to it. Are you writing to Status?
sta PRstReg,x reset 6551
L51.defs defines PRstReg as StatReg
StatReg is defined as port+1
Port is defined in systype but the code for init gets that with
ldx M$Mem,pcr get base hardware address again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've managed to pull out a box of 9 pin mice that I have and want to set up my RS-232 pak (actually a Ken-Ton dual RS-232 pak) to duplicate what you are seeing.
I have a 25 to 9 pin adapter plugged into the Ken-Ton's 25 pin connector, and the mouse is plugged into the 9 pin end of that adapter. I am not getting any response on the mouse, nor do I see the lock-up problem. I'm using joydrv_6551L as well. Are there any hardware hacks (i.e. line manipulations) that need to be done for the mouse to talk to the serial port?
Boisy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Disregard the previous post. I found Bruce Isted's original documents on the serial mouse, and modified my Ken-Ton pak to divert pin 16 of the 6551s to ground as per his instructions. I am now using joydrv_6551L with a Logitech mouse and am seeing similar behavior. The mouse must be moved in order for the boot to proceed.
Boisy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It has been YEARS since I set up a system with these serial mice, so it took me a while to re-acclimate myself to this setup and remember the issues surrounding using these serial mice.
As I indicated in an earlier post, I modified my Ken-Ton Dual Serial Pak to tie pin 16 (/DCD) of both 6551s to ground. In my pile of mice, I found two mice that worked: one with the joydrv_6551L driver and the other with the joydrv_6551M driver. Both appear to exhibit the same lockup behavior at bootup.
In the interest of taking one thing at a time, I'll focus on joydrv_6551L. One issue that came up is the MPI slot select, which is set to $00 in my joydrv_6551L. I noticed in the Init routine that a value of $80 or higher would cause a bmi to branch around the write to $FF7F. Changing the $00 to $FF got around the write to $FF7F, but with that change, the mouse quit responding.
Then I realized that without the $FF7F write, the IRQ from slot 1 wasn't making it to the 6551. My MPI does not have the *CART line strapped!
This is the whole reason that Tandy supplied that poor ModPak driver for its 300 baud Modem Pak. That driver latched on the 60Hz VIRQ and check the hardware for a ready character. Imagine polling the serial hardware 60 times per second... not an ideal solution for high speed serial communications.
There's no doubt that a *CART strapped MPI is a necessity to use serial mice.
With the mouse working, I ran Multi-Vue (the version in the repository) and I was able to move the mouse around on the screen, so it IS working.
Robert, I looked at your message regarding OS9 F$IRQ coming before the ORCC. I do not see that as being an issue. Typically, before tickling register that might cause an interrupt (even if interrupts are masked), it is a good practice to insure that an interrupt service routine is installed and prepared just in case a spurious interrupt may fire. So I would recommend NOT rearranging the order of the Init routine.
At this point, I don't have an idea as to why the boot process is stalling until a mouse move. I'll have to think about it.
I also suspect that some of the mice I have in my collection are putting out a packet that is different than what these modules are programmed for. That should be investigated as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regards OS9 F$IRQ, what I had in mind was preventing system response to spurious interrupts. That's what the orcc #$50 would do. With the interrupt installed before the PIA, GIME, MPI and 6551 are initialized, there's no telling what the system would do with a spurious interrupt.
Since we now have data that suggests the mouse itself is not being correctly initialized even though the system and 6551 are, perhaps the RTS line is not being help low for a long enough period of time.
Gene, the data you referenced, "The mouse driver can recognize a mouse by dropping RTS to low and raising it again. About 14 ms later the mouse will send 0x4D ('M') on the data line. After a further 63 ms, a Microsoft-compatible 3-button mouse will send 0x33 ('3')." and the fact that you have problems seeing the full mouse response, suggests a timing problem.
Perhaps the last step in the init sequence should be to re-toggle the RTS line with a long low period?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sta PRstReg,x reset 6551 That is, according to the docs I have, depends on the contents of regs A.
With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset.
What I'm doing is a full hardware reset by writing all zeros to both Command and Control registers, the n reloading them to the proper 1200 baud 8n1 configuration.
By doing what I'm doing, I have to flush 3 bytes from it at the reset, a '_M3' The M3 is supposed to be an indicator of the M$ 3 button protocol, but this obviously differs because a press or release of the middle button adds a 4 data byte to the packet, where the M$ protocol says it sends a 3 byte null packet for a middle button push.
The M$ spec says the 'M' byte is 14 milliseconds after the mouse is powered up, and if its a 3 button mouse, it will send an additional '3' 63 milliseconds after the M. But my first received char from the acia is an underscore, $7F, but I only see 2 chars go by on the scope, so I *think* the acia is catching the $7F thing because the mouse is slower to reach powerup than the acia is, so its a bit like seeing a break signal to the acia. I'll put that lda #$10, sta PRstReg,x in it tomorrow and see if the "_" disappears. I have doubts, but one never knows for sure till its tried. :)
I have an init routine just now that specifically gobbles up those 3 "_M3" bytes. This is booting ok, and everything seems to work UNTIL I move the mouse. Then it alternates between a dead keyboard (because its waiting on a 5 byte protocol mouse to finish sending the full 5 bytes I assume, or something along those lines) and working normally, dependent on where the mouse stopped moving.
Some of it can be simplified though, cuz I have timeout stops in it that will trigger if the mouse is too slow coming up after the reset. Those can go when its all working. Then the question becomes one of how can we use that response to auto configure the driver so all we have to do is change the drivers hardware address to where ever the users acia is actually addressed. We may be able to use that 4th byte to autoconfig it the first time it gets one. Otherwise if all 3 bytes are null data, use that as the middle button down signal.
You can find simplified data on these protocols at <http://linux,die.net/man/4/mouse>, and at <http://www.kryslix.com/nsfaq/Q.12.html>
Thanks, and goodnight.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
McDonald's -- Because you're worth it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
" sta PRstReg,x reset 6551 That is, according to the docs I have, depends on the contents of regs A.
With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset. "
I've a pdf of the data sheet, the specs from the Tandy manual on the RS-232 pak, and a reference on Sock's web sit. All of these say a write to the Status register ignores the data sent.
Just a clarification which probably has no bearing on your problem unless you have omitted writing to Status.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, in fact I was doing that write at a point well above that code, a $10, which acc my docs, does a full hardware reset. Testing shows I can leave the other command and control zeroing out, doesn't make any diff here.
The acia init routine got so long doing it sequentially that I crunched it down into subroutines, getting rid of about $40 bytes or more, but ATM I am having major problems getting conditional branches to behave.
Furinstance
Regs.a has the character 'M' in it, returned from GetByte
NxtByte ...
cmpa #'M
bne NxtByte
And it loops back to NxtByte, never falling through to
Get3Byt bsr GetByte
so it will get the final 3 from the mouses pwrup sequence.
Here is that snippet of code:
lrACIA ldx M$Mem,pcr get base hardware address again
lda #$10
sta StatReg,x reset again
ldd #(TIC.RTS!Cmd.DTR)*256+(DB.8!Ctl.RClk!BR.01200) [D]=command:control
std CmdReg,x set command and control registers
* do instant reads for trash collection
* and clear status of Stat.RxF bits
* read it 16 times!
ldb #$10
flshinit lda DataReg,x
lda StatReg,x
decb
bne flshinit
* that kills some of the 14 milliseconds
* to the mouses first response byte
* now, lets see what mouse we have
* prints __1MM1331tg
NxtByte bsr GetByte GetByte shows char, then this will too
ifeq DEBUG-1 debugging is killing me
pshs a,b,x,u,y,cc,dp
jsr <D.BtBug show this one
lda #'1 will repeat with the '_' throwaway
jsr <D.BtBug still in first char mode
puls a,b,x,u,y,cc,dp
endc
* this is NOT working when a=#'M ???
cmpa #'M some mice may not do '_' as they powerup
bne NxtByte skip to
bsr GetByte got _M, get 3
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
lda #'3 show we're in 3rd byte
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
cmpa #'3
beq GotByte
comb set error
GotByte rts
*********************************
* Entry : x pointing at hardware
* Mangles: a,b
* Returns: char in A
* Error : cc set, err code in B
* scans acia for a byte of data
GetByte pshs y
ldy #$01C0 set timeout to fail
GetByte1 leay -1,y
beq GByteFai
clra kill some time
Dly1 deca
bne Dly1
lda StatReg,x look for byte
anda Pkt.Mask,pcr
tsta Stat.RxF
beq GetByte1
* got a byte
lda DataReg,x
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
puls y
clrb in case cc set
rts
With DEBUG equ 1 at the top of the file, I'm getting
i2xo__1MM1331tg printed on the screen, and that final 1 tells me that
cmpa #'M some mice may not do '_' as they powerup
bne NxtByte skip to, will throw out the '_'
is not working cuz if it was I'd get
i2xo__1MM1333
and the boot would coninue. but since I'm stuck in the first loop due to the miss firing bne, it times out, adding the 'tg' from GByteFai routine and stalling so I can read the screen.
So what's wrong with that cmpa #'M, bne? As I understand it a cmp is a sub that throws away the answer but sets the z flag if the sub result=$00, otherwise clears the z flag, which is what beq and bne run on, right?
I reset the triggering on my scope, and I now see a period of about 1 bytes duration of near ground voltage before it resets to the - rail as its powering up, and I assume that is where I'm getting the initial $7F, "_" from the ACIA. Obviously other mice might behave differently. But if its there, throw it away.
ATM I'm going to dup that first loop as a second and drop the throwaway unless the failed conditional can be explained & made to work correctly. That means it may then be specific to my mouse and I don't like that idea either. My mouse could have a pwrup hiccup that others don't. And AFAIK, that is the only one I have, its been carefuly cleaned, buttons resoldered and maintained for 20 years now. :(
We'll get to the packet size issues when this is working.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At 1200 baud, the mouse at that point can wait a considerable amount of time.
Anyway I got that working, and turned off the jsr <D.BtBug noise and started on the IRQSvs routine. The first thing I run into is that in l151.defs, both SyncData and SyncMask are wrong.
These are 7 bit devices, and bit d7 is not used for anything even if it is transmitted by the mouse.
So SyncData needs to be changed from its current binary 10000000, to 01000000, or #$40, which I've done in that code now.
Then SyncMask is similarly wrong it should not be 11111000=$F8, but 01111000=$78 and I have changed that also.
Stat.IRQ is correct as thats read from the acia. PktSize s/b 4 maybe, but we'll cross that when we get there.
Humm, fixing that made the mouse virtually kill the keyboard. Just for grins I'm going to put a read and do nothing return there.
That fixes about 98% of the keyboard lockouts.
But not all, so that is not the right fix.
Grepping thru the srcs, I note there are many more orcc #IntMask's than there are andcc #^IntMask
There is no IRQ re-enable (there is a disable) other than pulling cc in joydrv_6551L.asm, so I'm assuming the dispatcher is supposed to do that when it returns from calling the devices IRQSvs routine?
I take it the actual interrupt dispatcher is in krn.asm?
I need to go warm up the grill, maybe back later. About burned out with obtuse code for today.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The revolution will not be televised.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?
I'm not, but this driver seems to have been written with that in mind, none of the code I'm looking at make any sense at all with either an M$ 3 byte mouse, or a Logitek 3+1 mouse, almost identical mice.
Where the two differ is in how they handle the 3rd, center button of a 3 button mouse. M$ it says here, (http://www.kryslix.com/nsfaq/Q.12.html)uses an empty packet to send a middle button down event and any other data in the packet indicates 3rd button up, whereas the logitek mice are identical to the M$ in data format EXCEPT for the middle button. IN the event of a middle button down event, the logitek sends a 4th byte with D5 set, a($20) or with it clear=$00 when the button is released. Otherwise its identical the the M$ driver for a 2 button mouse.
See page 2 of that link for a graphical representation of the bit assignments in the 3 byte packet of an M$ mouse. Then add a 4th byte only for a 3rd, middle button event.
Note that the first byte contains the 2 MSB's of a 8 bit value for each direction that represents the vector motion since the last packet was sent. The MSB of each(y-d3,x=d1) are sign bits to tell which way it has moved since the last packet.
In fact, I think I am going to forget working on this driver, and see if the 6551M driver makes more sense. If it does, then I'll blow this one away, copy the M version to the L version and modify it to handle the middle butons 4th byte. That of course depends on whether or not the M driver makes sense.
I did a couple of experiments today is all, and may not have time to fool with it tomorrow as I'm due to have some of my test gear at a local radio station at 10ish in the morning & see if we can figure out why its dropping power from 25kw to maybe 7kw when the VSWR shows quite low on one meter, but another at the final output says its getting 20% of the output power back from someplace.
What I found is that if I do nothing but read the data that caused the IRQ, and skip to the return code, it works fine, UNTIL I move the mouse, then the keyboard is blocked, and I suspect that is because someplace in the return path from the irq service routine, the interrupts are not being re-enabled, so the keyboard IRQ never is recognized. Moving the mouse may get it to take a key now and then, but be gentle cuz it will eventually go completely away in a screen full of nicely colored confetti.
Now, when the system boots, I would _think_ that by the time Sysgo is running the startup script, that I should be able to run 'irqs' from the startup script, but without at least a sleep 50 as the next to the last command in the startup, irqs is fetching totally trashed data, particularly with regard to the owner of that interrupt, in one of them when I only had a sleep 10 in there, it actually showed 5 IRQ's, claiming they all belonged to rb1773? Hit the reset button again, and the next time it might show garbage hex data there, add a few more ticks to the sleep, and its output becomes normal. Normal looks like this:
The top one is the shell running on /t2 of course. The bottom one is the mouse. But its showing the thing as belonging to sc6551, and I am under the impression that this driver is 100% self contained, so the sc6551 reference is as bogus as a $3 bill AFAIAC. Am I wrong somehow?
So, have a fine one guys. I'm only going to do one more build and test cycle using the M$ driver tonight since I have to be awake a bit earlier than is normal for this old fart tomorrow.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The revolution will not be televised.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I sent you both an email with an attachment, and that totally fixed the keyboard lockout problems woith an IRQSvs routine that does nothing but read the data from the acia and throw it away.
Now, I've found a dis of a cc3io I did in late 93, at a time when I believe the mouse was working nicely, and I sent that also. Then in some more trolling through that maxtor copy, I found a cc3io.dr module a few bytes longer yet, and dated in December 94, carrying the name cc3io_m51.mine.
Now the question is, do we have in the toolshed, a disassembler, like sleuth or disasm? Taking it apart on this system would be a lot faster.
That .dis file I sent is os9 style eol's, I can't seem to make tr work to translate them, and it would be half a day in vim to hand convert it. Is there another way?
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The universe is like a safe to which there is a combination -- but the
combination is locked up in the safe.
-- Peter DeVries
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I built a joydrv_6551L.sb that saves the slot select, put it on the slot 0, does its thing and then restores the original slot # on exit. This read, according the <D.BtBug as 3 on the first boot attempt, but it still seems to do a puls pc,cc into never never land, except that about 10 minutes later, while I'm studying the listing, up popped a green screen with part of sysgo's output on it, but it then failed at the date t display.
On several reboots, including a powerdown reset for about 30 seconds, it is now displaying a '/' in place of the 3. To display a '/' there, with this code:
lda #'0
adda SlotSave, pcr
jsr <D.BtBug
it has to be reading $FF from SlotSave,pcr, which was originally written:
SlotSlct fcb MPISlot
SlotSave fcb MPISlot scratchpad space
[...]
lda >MPI.Slct which assembles as $B6FF7F
sta SlotSave,pcr
I just ran through the assembled defs 3 times without finding a location, hopefully in DP, that records the current MPI.Slot! From that I have to assume that $FF7F is both readable and writable.
So how do we keep track of it?
--
Cheers, Gene
Here is the email:
------------
Hi Guys;
>The size limit applies to 6809 boot files not 6309. It could well be a
>'new' bug but Boisy reminded me this was discussed previously in the
>defunct NitrOS-9 newsgroup/mailing list.
>I don't recall this existing in stock OS-9 Level2 or the original
>NitrOS-9 (Gale Force) versions. There were massive changes made to
>modules when Boisy decided there should be as much common source code as
>possible so Level1, Level2, Level3, and 6809/6309 could be generated
>from the same source code. This bug could easily have been introduced in
>this period.
>
>You can make finding the source of the memory limit bug your next
>project after you solve your joystick problem. :)
I think it also applies to 6309 machines as well. I put my bootlist on a diet
and got it down to a few bytes over 32k, and with a few caveats, it is working.
Sorta.
1. I have a scope on the mouses output, and I can see the blinking in the video
when I move the mouse, which tells me the IRQ line is being pulled down in
response to the mouse data coming in, and that the IRQ is being serviced
because the blinking is for as long as I'm moving the mouse, or pressing and
releasing a button on it. Before, it was never being initialized enough to
register and enable the chip to issue IRQ's, so this is progress. This is with
joydrv_6551L.sb set for a mouse address of $FF6C. Now, irqs says its there,
and at $FF6D.
2. On a reboot, back to this same disk, the boot will stall at about joydrv
init, and wait either for the rapture, or for me to move the mouse a fraction
of an inch. This says to me that the IRQ routine isn't being installed before
the chipset is properly init'ed and flushed of any pending data. Should we not
re-arrange that order somehow, but first disabling the chips ability to
generate an IRQ, then flush it, then install the IRQSvs, and then enable the
chip?
3. Multivue still cannot see the mouse, so I'm stuck with a useless multivue
screen I can't get rid of till a reboot is done. I looked at /dd/sys/env.file,
but that doesn't tell gshell where the mouse is & 15 years ago ISTR there was a
place/file that did tell gshell where it was.
Now, from reading the multivue book on mouse use, it reads like it shouldn't
really care what PTRSID is set to in the env.file as long as the joydrv
SS.Mouse call works. So I'm confused. Its currently, and was 15 years ago
when this all worked but before all this 'modularization', set to PTRSID=1.
What, if anything should it be set to now with this new joydrv thing? Back
then I *think* it was part of cc3io or??
--------------------
I also found what I'd sure call a bug in os9gen, it is treating an empty line in
bootlists/genes.bl as the eof, stopping the generation of the os9boot file at
that point, and w/o any reported error. I don't know when that crept into the
file, but I expect that has been part of my trouble every since the high window
descriptors were all found to be copies of each other. That really ought to be
fixed at some point so it doesn't bail out till it gets a real eof from the
filesystem.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
--------------
11:44 Saturday June 7th, 2008
I remember years ago when using OS-9 Level II that I had the same issue with joydrv for the 6551. Until I moved the mouse, OS-9 wouldn't fully come up. I don't have this setup any longer, so I cannot assist in debugging.
Some investigation will be required to understand why moving the mouse is necessary. I wonder where in the source that things could be "locked up" until the mouse moves.
As for os9gen, the behavior you described is not a bug. os9gen has always worked this way.
Gene, you have a point about joydrv_6551L.asm. Currently the init routine installs an IRQ before initializing the PIAs. That alone does not make sense. The order in init should be
suspend all interrupts
initialize PIAs, GIME, and MPI slot
send command (if there is one) to the 6551 to halt/reset
clear all flags
engage interrupts
It would be easy enough to relocate the OS9 F$IRQ to the end of the init routine. There is no equivalent to a 6551 Reset command in the code but if there is a Reset, it could be added.
Want to rewrite init and test it?
The info in the RS-232 manual has a table indicating a write to $FF69 is a forced soft reset. Specifically, "A res* from the bus will clear all registers in the 6551, while a soft reset will only disable interrupts and transmitter, turn off the echo mode, and clear the overrun flag." Ambiguously, the manual also states, "The soft reset opertion clears the 6551 internal registers but does not cause any data transfer."
So, does a soft reset clear all registers or only a hardware res* ?
In either case, joydrv_6551L.asm does send a soft reset command to the 6551 in the init routine.
orcc #IntMasks disable IRQs while setting up hardware
sta PRstReg,x reset 6551
PRstReg is defined in l51.defs as $ff69 so the code is clearing the 6551 as best as is possible. The only problem, in my opinion, is the orcc comes too late in the routine, after the OS9 F$IRQ call.
Hi Guys;
suspend all interrupts
initialize PIAs, GIME, and MPI slot
send command (if there is one) to the 6551 to halt/reset
clear all flags
engage interrupts
That makes sense to me. At present, I am getting an "IRQ Storm" as soon as it has been init'ed. Also the scope says it is outputting a packet, maybe more, of data when the acia is enabled, which in turn powers up the mouse since it is powered from the acia lines.
As for this:
"PRstReg is defined in l51.defs as $ff69", note that is PRstReg,x and PRstReg is actually an offset of 1 and in this code x=$ff6C (I hope anyway) so that write would be correctly made to $FF6D.
However, even if I do move the mouse in time and it boots fully, multivue still can't find it. But I suspect that is a different beast entirely. :-) It does show up in the irqs report then, unlike the boot it is booted to now, where only the /t2 irq is showing. But that boot with a mouse will not format a floppy. This one will.
{t2|08}/DD/NITROS9/6309L2/MODULES/SCF:irqs
Polling Table at: 5DFB
Device Table at: 5C00
Device Driver IRQ Flip
Port Mem Name Vector &Mask Pty
---- ---- ------------ ----- ---
FF69 4C00 sc6551 E392 00 88 0A
Thanks for any more insight you can toss my way, I'm not exactly a 6551 guru. OTOH, I have found some nice info on this drain bamaged chip on the net, complete with workarounds for the ugliest bug related to CTS dropping in mid char.
One last thought, I've set the watch bit on this forum, which means I should be getting an email alert when a new post is made. I am not getting these, and someone please check why?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
In matters of principle, stand like a rock;
in matters of taste, swim with the current.
-- Thomas Jefferson
Gene,
Please let us know what the outcome is when you rearrange the code. The ideal scenario is to not have NitrOS-9 wait for the mouse to move.
I'm anxious to see you results.
Boisy
Hi again Guys;
I've re-written it to do things in the order suggested by Robert. The reboot still hangs at i2xoXXX where X is a char I put in to indicate the execution of each of the 3 subroutines I made out of the individual pieces of code. I also commented out a boatload of code that was never called in the original version 6.
Now I push cc and disable the interrupts
Init the PIA's. GIME and MPI.slot (subroutine 'P')
reset the acia
clear the 8 byte wide buffer U points at
Init some of that buffer to starter values as before, but I'm not sure they are correct
read the chip to clear pending data as originally done, take exit if it won't clear on 2nd read as before
Install the svs routine with I$IRQ as before
enable the interrupts by pulling cc.
Now it will boot after outputting the tallies I put in the 3 subroutines I made of the above.
With these caveats of course:
at i2xoXXX, I have to move the mouse for it to proceed, but it then booted normally, initing all 4 screens I normally used and the shell on /t2.
However, the keyboard seems to be blocked until the mouse is moved, even just to service the clear key to switch screens! After quite a bit of that it seemed to get well and I could run utils from one of the screens. Multivue still can't find the mouse however, the pointer is stuck in the upper left corner.
The shell on /t2 I'm looking at here seems to be functional, a dir -e works, and an irqs shows:
{t2|08}/DD:irqs
Polling Table at: 6AFB
Device Table at: 6900
Device Driver IRQ Flip
Port Mem Name Vector &Mask Pty
---- ---- ------------ ----- ---
FF69 5300 sc6551 E3B7 00 88 0A
FF6D 10EC sc6551 B7E7 00 0F 01
Now, I'm about burned out for the day. I would like to put this code up so others can play & offer insight, or finish the fixing maybe, but my asking for instructions on how to use cvs to update a single, or maybe 2 or 3 files (joydrv_6551L.asm, dcheck.asm, and vtio.asm) in the repo have been ignored. I think now that there may be bogus control data being written either to PIA(0/1?), or to the 6551 itself.
I also added a counter output to the normal exit of the IRQSvs routine so I could see the byte count building up in buffer,u, but that is covered by the green screen in milliseconds after I move the mouse to generate that data. My persistence of vision isn't THAT good. :)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Gene,
Good progress made. If you want to commit your changes, change to the directory where the files are and type:
cvs commit
You should be able to commit them that way.
Boisy
CVS: Modified Files:
CVS: joydrv_6551L.asm joydrv_6552L.asm scf.asm snddrv_cc3.asm
CVS: vtio.asm kernel/krnp2.asm
I think there are no substantive changes in scf.asm or krnp2.asm. Some tally outputs in the others added to trace things, and those can go as easily as they were added. joydrv_651L.asm is the biggie.
Does it ever tell me when its done?
I think I might have a handle on the irq lockup/storm, I believe the control register is getting set so an IRQ is generated for a TBE condition, which would always be true. I've downloaded the WDC version of the docs, 34 pages of dead tree now, and will see if I can get that sorted one way or the other.
But I am still not getting emails from srcforge when you all post replies. I did when I first signed up, but no more, and there is a checkmark beside the watch this on the forum's top page.
I did a forced exit, used a ! to reuse that log the next time, and then got informed I need write access to do that, bummer. So I suspect the repo is not touched.
--
Cheers, Gene
Robert went through the exercise recently of setting up his copy of the repository. You have CVS access to the project so you should be able to make commits IF you have checked out the repository as a user and not anonymously.
As far as monitoring the forum, I have this forum monitored and I get emails when you or anyone else posts here. I would check to see if your account has a current email on file.
Boisy
I'll do that. In the meantime this joydrv_6551L.asm seems to be set for some 5 byte packet protocol, and the logitek is a 3+1 protocol, the +1 (4th byte) being only for a middle button event. So that part of it is going to need a major rewrite as its expecting 5 bytes per packet.
In the meantime, the protocol says that on cycleing RTS, it will spit out the first of 2 ID bytes about 14ms later, followed by a second 'variation' byte about 63 milliseconds after that. I see 2, separated by about those times, bytes being sent by the mouse after the hardware reset and re-init I'm doing in this code ATM.
I've written it so that it should spit out those 2 bytes, they are supposed to be printable ascii bytes, to the screen during the init, then output a "S" to indicate its frozen there so I can read what it says between the i2xoPG and the S, but all I'm getting is i2xoPGS
Here is that code snippet from the listing:
00202 0086 AE8DFF81 ClrACIA ldx M$Mem,pcr get base h
00203 008A 4F clra
00204 008B 5F clrb
00205 008C ED02 std CmdReg,x do full hd
00206 * loads $0918, $09 to CmdReg=tx irq dis, no par, tx low
00207 * $18 to CtrlReg= 1200 baud 1 stop
00208 008E CC0918 ldd #(TIC.RTS!Cmd.DTR)*256+(DB.8!C
00209 0091 ED02 std CmdReg,x set comman
00210 0093 3420 pshs y
00211 0095 108E0000 ldy #$0000 long delay
00212 0099 313F NxtByte leay -1,y start cntr
00213 009B 2712 beq NxtBExit was InitEr
00214 009D A601 lda StatReg,x *Rx data,
00215 * this doesn't check TBE or IRQ
00216 009F A48DFF82 anda Pkt.Mask,pcr IRQ bits s
00217 00A3 27F4 beq NxtByte repeat 655
00218 00A5 9408 anda Stat.RxF got byte?
00219 00A7 27F0 beq NxtByte no, try ag
00220 * got a data byte, show it
00221 00A9 A684 lda DataReg,x get ID byt
00222 00AB 9D5E jsr <D.BtBug what was i
00223 00AD 20EA bra NxtByte there may
00224 * temp stopper
00225 00AF 3520 NxtBExit puls y fix stack
00226 * show we're stuck here
00227 00B1 8653 lda #'S
00228 00B3 9D5E jsr <D.BtBug
00229 00B5 20FE letmesee bra letmesee
00230 00B7 39 rts
If it was an M$ 3 button mouse, I should be seeing "i2xoPG'M3'S" there, so I'd assume for a logitek, it might be something like "i2xoPG'L3'S". But all I'm getting is "i2xoPGS", and the mouse is sending the 2 bytes of data, I can see it on the scope I have hooked up as it goes by. Obviously there is something wrong with my conditional branching above, but I can't see it.
One step at a time here, before I go charging off in all directions at once.
PktMask=$0F, and Stat.RxF=$08, correct according to the docs from WDC, who is making a cmos version of this chip. Nice docs too.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The curse of the Irish is not that they don't know the words to a song --
it's that they know them *___all*.
-- Susan Dooley
Gene,
It's hard to tell without seeing your complete code for the init routine but the snipit posted seems to be missing something. When you reset the 6551 you not only should read the status register but should also write to it. Are you writing to Status?
sta PRstReg,x reset 6551
L51.defs defines PRstReg as StatReg
StatReg is defined as port+1
Port is defined in systype but the code for init gets that with
ldx M$Mem,pcr get base hardware address again
Gene,
I've managed to pull out a box of 9 pin mice that I have and want to set up my RS-232 pak (actually a Ken-Ton dual RS-232 pak) to duplicate what you are seeing.
I have a 25 to 9 pin adapter plugged into the Ken-Ton's 25 pin connector, and the mouse is plugged into the 9 pin end of that adapter. I am not getting any response on the mouse, nor do I see the lock-up problem. I'm using joydrv_6551L as well. Are there any hardware hacks (i.e. line manipulations) that need to be done for the mouse to talk to the serial port?
Boisy
Gene,
Disregard the previous post. I found Bruce Isted's original documents on the serial mouse, and modified my Ken-Ton pak to divert pin 16 of the 6551s to ground as per his instructions. I am now using joydrv_6551L with a Logitech mouse and am seeing similar behavior. The mouse must be moved in order for the boot to proceed.
Boisy
It has been YEARS since I set up a system with these serial mice, so it took me a while to re-acclimate myself to this setup and remember the issues surrounding using these serial mice.
As I indicated in an earlier post, I modified my Ken-Ton Dual Serial Pak to tie pin 16 (/DCD) of both 6551s to ground. In my pile of mice, I found two mice that worked: one with the joydrv_6551L driver and the other with the joydrv_6551M driver. Both appear to exhibit the same lockup behavior at bootup.
In the interest of taking one thing at a time, I'll focus on joydrv_6551L. One issue that came up is the MPI slot select, which is set to $00 in my joydrv_6551L. I noticed in the Init routine that a value of $80 or higher would cause a bmi to branch around the write to $FF7F. Changing the $00 to $FF got around the write to $FF7F, but with that change, the mouse quit responding.
Then I realized that without the $FF7F write, the IRQ from slot 1 wasn't making it to the 6551. My MPI does not have the *CART line strapped!
This is the whole reason that Tandy supplied that poor ModPak driver for its 300 baud Modem Pak. That driver latched on the 60Hz VIRQ and check the hardware for a ready character. Imagine polling the serial hardware 60 times per second... not an ideal solution for high speed serial communications.
There's no doubt that a *CART strapped MPI is a necessity to use serial mice.
With the mouse working, I ran Multi-Vue (the version in the repository) and I was able to move the mouse around on the screen, so it IS working.
Robert, I looked at your message regarding OS9 F$IRQ coming before the ORCC. I do not see that as being an issue. Typically, before tickling register that might cause an interrupt (even if interrupts are masked), it is a good practice to insure that an interrupt service routine is installed and prepared just in case a spurious interrupt may fire. So I would recommend NOT rearranging the order of the Init routine.
At this point, I don't have an idea as to why the boot process is stalling until a mouse move. I'll have to think about it.
I also suspect that some of the mice I have in my collection are putting out a packet that is different than what these modules are programmed for. That should be investigated as well.
Regards OS9 F$IRQ, what I had in mind was preventing system response to spurious interrupts. That's what the orcc #$50 would do. With the interrupt installed before the PIA, GIME, MPI and 6551 are initialized, there's no telling what the system would do with a spurious interrupt.
Since we now have data that suggests the mouse itself is not being correctly initialized even though the system and 6551 are, perhaps the RTS line is not being help low for a long enough period of time.
Gene, the data you referenced, "The mouse driver can recognize a mouse by dropping RTS to low and raising it again. About 14 ms later the mouse will send 0x4D ('M') on the data line. After a further 63 ms, a Microsoft-compatible 3-button mouse will send 0x33 ('3')." and the fact that you have problems seeing the full mouse response, suggests a timing problem.
Perhaps the last step in the init sequence should be to re-toggle the RTS line with a long low period?
sta PRstReg,x reset 6551 That is, according to the docs I have, depends on the contents of regs A.
With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset.
What I'm doing is a full hardware reset by writing all zeros to both Command and Control registers, the n reloading them to the proper 1200 baud 8n1 configuration.
By doing what I'm doing, I have to flush 3 bytes from it at the reset, a '_M3' The M3 is supposed to be an indicator of the M$ 3 button protocol, but this obviously differs because a press or release of the middle button adds a 4 data byte to the packet, where the M$ protocol says it sends a 3 byte null packet for a middle button push.
The M$ spec says the 'M' byte is 14 milliseconds after the mouse is powered up, and if its a 3 button mouse, it will send an additional '3' 63 milliseconds after the M. But my first received char from the acia is an underscore, $7F, but I only see 2 chars go by on the scope, so I *think* the acia is catching the $7F thing because the mouse is slower to reach powerup than the acia is, so its a bit like seeing a break signal to the acia. I'll put that lda #$10, sta PRstReg,x in it tomorrow and see if the "_" disappears. I have doubts, but one never knows for sure till its tried. :)
I have an init routine just now that specifically gobbles up those 3 "_M3" bytes. This is booting ok, and everything seems to work UNTIL I move the mouse. Then it alternates between a dead keyboard (because its waiting on a 5 byte protocol mouse to finish sending the full 5 bytes I assume, or something along those lines) and working normally, dependent on where the mouse stopped moving.
Some of it can be simplified though, cuz I have timeout stops in it that will trigger if the mouse is too slow coming up after the reset. Those can go when its all working. Then the question becomes one of how can we use that response to auto configure the driver so all we have to do is change the drivers hardware address to where ever the users acia is actually addressed. We may be able to use that 4th byte to autoconfig it the first time it gets one. Otherwise if all 3 bytes are null data, use that as the middle button down signal.
You can find simplified data on these protocols at <http://linux,die.net/man/4/mouse>, and at <http://www.kryslix.com/nsfaq/Q.12.html>
Thanks, and goodnight.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
McDonald's -- Because you're worth it.
I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?
" sta PRstReg,x reset 6551 That is, according to the docs I have, depends on the contents of regs A.
With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset. "
I've a pdf of the data sheet, the specs from the Tandy manual on the RS-232 pak, and a reference on Sock's web sit. All of these say a write to the Status register ignores the data sent.
Just a clarification which probably has no bearing on your problem unless you have omitted writing to Status.
No, in fact I was doing that write at a point well above that code, a $10, which acc my docs, does a full hardware reset. Testing shows I can leave the other command and control zeroing out, doesn't make any diff here.
The acia init routine got so long doing it sequentially that I crunched it down into subroutines, getting rid of about $40 bytes or more, but ATM I am having major problems getting conditional branches to behave.
Furinstance
Regs.a has the character 'M' in it, returned from GetByte
NxtByte ...
cmpa #'M
bne NxtByte
And it loops back to NxtByte, never falling through to
Get3Byt bsr GetByte
so it will get the final 3 from the mouses pwrup sequence.
Here is that snippet of code:
lrACIA ldx M$Mem,pcr get base hardware address again
lda #$10
sta StatReg,x reset again
ldd #(TIC.RTS!Cmd.DTR)*256+(DB.8!Ctl.RClk!BR.01200) [D]=command:control
std CmdReg,x set command and control registers
* do instant reads for trash collection
* and clear status of Stat.RxF bits
* read it 16 times!
ldb #$10
flshinit lda DataReg,x
lda StatReg,x
decb
bne flshinit
* that kills some of the 14 milliseconds
* to the mouses first response byte
* now, lets see what mouse we have
* prints __1MM1331tg
NxtByte bsr GetByte GetByte shows char, then this will too
ifeq DEBUG-1 debugging is killing me
pshs a,b,x,u,y,cc,dp
jsr <D.BtBug show this one
lda #'1 will repeat with the '_' throwaway
jsr <D.BtBug still in first char mode
puls a,b,x,u,y,cc,dp
endc
* this is NOT working when a=#'M ???
cmpa #'M some mice may not do '_' as they powerup
bne NxtByte skip to
bsr GetByte got _M, get 3
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
lda #'3 show we're in 3rd byte
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
cmpa #'3
beq GotByte
comb set error
GotByte rts
*********************************
* Entry : x pointing at hardware
* Mangles: a,b
* Returns: char in A
* Error : cc set, err code in B
* scans acia for a byte of data
GetByte pshs y
ldy #$01C0 set timeout to fail
GetByte1 leay -1,y
beq GByteFai
clra kill some time
Dly1 deca
bne Dly1
lda StatReg,x look for byte
anda Pkt.Mask,pcr
tsta Stat.RxF
beq GetByte1
* got a byte
lda DataReg,x
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
puls y
clrb in case cc set
rts
GByteFai puls y
clrb clear carry
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
lda #'t indicate timeout
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
GBytFail equ *
ifeq DEBUG-1
pshs a,b,x,u,y,cc,dp
lda #'g GByt stuff failed
jsr <D.BtBug
puls a,b,x,u,y,cc,dp
endc
comb set carry
ldb #E$PrcAbt
ifeq DEBUG-1
lettgsho bra lettgsho
endc
rts
With DEBUG equ 1 at the top of the file, I'm getting
i2xo__1MM1331tg printed on the screen, and that final 1 tells me that
cmpa #'M some mice may not do '_' as they powerup
bne NxtByte skip to, will throw out the '_'
is not working cuz if it was I'd get
i2xo__1MM1333
and the boot would coninue. but since I'm stuck in the first loop due to the miss firing bne, it times out, adding the 'tg' from GByteFai routine and stalling so I can read the screen.
So what's wrong with that cmpa #'M, bne? As I understand it a cmp is a sub that throws away the answer but sets the z flag if the sub result=$00, otherwise clears the z flag, which is what beq and bne run on, right?
I reset the triggering on my scope, and I now see a period of about 1 bytes duration of near ground voltage before it resets to the - rail as its powering up, and I assume that is where I'm getting the initial $7F, "_" from the ACIA. Obviously other mice might behave differently. But if its there, throw it away.
ATM I'm going to dup that first loop as a second and drop the throwaway unless the failed conditional can be explained & made to work correctly. That means it may then be specific to my mouse and I don't like that idea either. My mouse could have a pwrup hiccup that others don't. And AFAIK, that is the only one I have, its been carefuly cleaned, buttons resoldered and maintained for 20 years now. :(
We'll get to the packet size issues when this is working.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
What happens if you remove the
cmpa #'M some mice may not do '_' as they powerup
bne NxtByte skip to
Does the boot continue or still fail?
When you use the jsr <D.BtBug routine, the interrupts will be temporarily turned off. That might cause you to lose data from the mouse.
At 1200 baud, the mouse at that point can wait a considerable amount of time.
Anyway I got that working, and turned off the jsr <D.BtBug noise and started on the IRQSvs routine. The first thing I run into is that in l151.defs, both SyncData and SyncMask are wrong.
These are 7 bit devices, and bit d7 is not used for anything even if it is transmitted by the mouse.
So SyncData needs to be changed from its current binary 10000000, to 01000000, or #$40, which I've done in that code now.
Then SyncMask is similarly wrong it should not be 11111000=$F8, but 01111000=$78 and I have changed that also.
Stat.IRQ is correct as thats read from the acia. PktSize s/b 4 maybe, but we'll cross that when we get there.
Humm, fixing that made the mouse virtually kill the keyboard. Just for grins I'm going to put a read and do nothing return there.
That fixes about 98% of the keyboard lockouts.
But not all, so that is not the right fix.
Grepping thru the srcs, I note there are many more orcc #IntMask's than there are andcc #^IntMask
There is no IRQ re-enable (there is a disable) other than pulling cc in joydrv_6551L.asm, so I'm assuming the dispatcher is supposed to do that when it returns from calling the devices IRQSvs routine?
I take it the actual interrupt dispatcher is in krn.asm?
I need to go warm up the grill, maybe back later. About burned out with obtuse code for today.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The revolution will not be televised.
Robert Gault said a couple of days ago:
I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?
I'm not, but this driver seems to have been written with that in mind, none of the code I'm looking at make any sense at all with either an M$ 3 byte mouse, or a Logitek 3+1 mouse, almost identical mice.
Where the two differ is in how they handle the 3rd, center button of a 3 button mouse. M$ it says here, (http://www.kryslix.com/nsfaq/Q.12.html)uses an empty packet to send a middle button down event and any other data in the packet indicates 3rd button up, whereas the logitek mice are identical to the M$ in data format EXCEPT for the middle button. IN the event of a middle button down event, the logitek sends a 4th byte with D5 set, a($20) or with it clear=$00 when the button is released. Otherwise its identical the the M$ driver for a 2 button mouse.
See page 2 of that link for a graphical representation of the bit assignments in the 3 byte packet of an M$ mouse. Then add a 4th byte only for a 3rd, middle button event.
Note that the first byte contains the 2 MSB's of a 8 bit value for each direction that represents the vector motion since the last packet was sent. The MSB of each(y-d3,x=d1) are sign bits to tell which way it has moved since the last packet.
In fact, I think I am going to forget working on this driver, and see if the 6551M driver makes more sense. If it does, then I'll blow this one away, copy the M version to the L version and modify it to handle the middle butons 4th byte. That of course depends on whether or not the M driver makes sense.
I did a couple of experiments today is all, and may not have time to fool with it tomorrow as I'm due to have some of my test gear at a local radio station at 10ish in the morning & see if we can figure out why its dropping power from 25kw to maybe 7kw when the VSWR shows quite low on one meter, but another at the final output says its getting 20% of the output power back from someplace.
What I found is that if I do nothing but read the data that caused the IRQ, and skip to the return code, it works fine, UNTIL I move the mouse, then the keyboard is blocked, and I suspect that is because someplace in the return path from the irq service routine, the interrupts are not being re-enabled, so the keyboard IRQ never is recognized. Moving the mouse may get it to take a key now and then, but be gentle cuz it will eventually go completely away in a screen full of nicely colored confetti.
Now, when the system boots, I would _think_ that by the time Sysgo is running the startup script, that I should be able to run 'irqs' from the startup script, but without at least a sleep 50 as the next to the last command in the startup, irqs is fetching totally trashed data, particularly with regard to the owner of that interrupt, in one of them when I only had a sleep 10 in there, it actually showed 5 IRQ's, claiming they all belonged to rb1773? Hit the reset button again, and the next time it might show garbage hex data there, add a few more ticks to the sleep, and its output becomes normal. Normal looks like this:
{t2|08}/DD/NITROS9/6309L2/MODULES/SCF:irqs
Polling Table at: 6AFB
Device Table at: 6900
Device Driver IRQ Flip
Port Mem Name Vector &Mask Pty
---- ---- ------------ ----- ---
FF69 4700 sc6551 E3D0 00 88 0A
FF6D 10EC sc6551 B808 00 0F 01
The top one is the shell running on /t2 of course. The bottom one is the mouse. But its showing the thing as belonging to sc6551, and I am under the impression that this driver is 100% self contained, so the sc6551 reference is as bogus as a $3 bill AFAIAC. Am I wrong somehow?
So, have a fine one guys. I'm only going to do one more build and test cycle using the M$ driver tonight since I have to be awake a bit earlier than is normal for this old fart tomorrow.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The revolution will not be televised.
Hi Guys;
I sent you both an email with an attachment, and that totally fixed the keyboard lockout problems woith an IRQSvs routine that does nothing but read the data from the acia and throw it away.
Now, I've found a dis of a cc3io I did in late 93, at a time when I believe the mouse was working nicely, and I sent that also. Then in some more trolling through that maxtor copy, I found a cc3io.dr module a few bytes longer yet, and dated in December 94, carrying the name cc3io_m51.mine.
Now the question is, do we have in the toolshed, a disassembler, like sleuth or disasm? Taking it apart on this system would be a lot faster.
That .dis file I sent is os9 style eol's, I can't seem to make tr work to translate them, and it would be half a day in vim to hand convert it. Is there another way?
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The universe is like a safe to which there is a combination -- but the
combination is locked up in the safe.
-- Peter DeVries