Raven 060 (sety's build)

[sety]

I’m using USB mouse+keyboard now with an earlier protoype version of this:
https://github.com/agranlund/raven/tree ... rades/ckbd

That looks awesome! Are you picturing any major changes to the prototype PCB? I'm almost tempted to send it to production early.

I'm starting to think that there is something odd going on in my PIC chip. I'll try testing it outside of the system when I get home.

[sety]

@sety just a thought, how's the ground connection on the mouse? I had a socket with a dodgy ground and it used to be intermittent as well.

I'll check it when I get home. Thanks

[kodak80]

I’m using USB mouse+keyboard now with an earlier protoype version of this:
https://github.com/agranlund/raven/tree ... rades/ckbd

I have not yet built that particular version, nor adjusted the firmware for it, but PCBs are supposedly
In transit so it shall be done once they arrive.
Could be an option if you can’t get the PS2 mouse working or just rather want to use USB devices?

I jumped the gun and already ordered these PCBs. I have 5 here and would be willing to share 1 with the Aussie contingent if this helps. Just waiting on the chip to arrive and information on the new firmware for the chip.

IMG_1142.JPG (337.91 KiB) Viewed 1717 times

[agranlund]

Cool! I had a look at the tracking and mine are apparently in the country and should be here any day
I expect that firmware changes from the prototype board to this version should be quite minor as it's mostly a couple of pinout changes for the ch559.

[agranlund]

I jumped the gun and already ordered these PCBs.

I've built mine today and from an initial quick test the hardware appears to work.
Though it looks like there's an important software issues to fix before it's properly usable -- I tried a non-debug build for the first time and notice mouse isn't entirely happy (same behaviour for usb, ps2 and joyport mice which I'm happy about since that strongly indicates a problem in the common mouse code)

I'm sure more stuff will be found when the more uncommon ikbd modes are tested too so don't throw away that Eiffel PIC just yet

Unimplemented so far:
- fan control
- cpu temp (requires motherboard patch wire)
- software power-off (requires motherboard patch wire + Raven support in MiNT)

Untested so far:
- joyport mouse right button (requires motherboard patch wire)

You shouldn't need to solder J104 if you don't want to, but it also won't hurt it you do.
Normal operation is having the header completely open (support for external oscillator is not implemented)
First-time programming can be done without jumpering for programming mode, and subsequent programming can be initiated from software. Jumpering for programming mode should only be needed if it for some reason ends up bricked.
Pin0 is 115200 baud serial output for debug builds of the firmware

Also don't forget to remove the pin for the key position if you're using a normal 2x5 pinheader on J103

Screenshot 2025-06-18 at 23.21.49.png (463.12 KiB) Viewed 1657 times

[sety]

Aww poop! I was almost there! But I've broken something and don't know where to start looking.

Crash.jpg (286.15 KiB) Viewed 1634 times

This from the last few lines of TOS boot:

Code: Select all

init_acia_vecs()
after init_acia_vecs()
calibrate_delay()
Panic: Exception number 100
sr=2000 pc=00e0c8ac

D0-3: 00a65223 00000020 00000000 0001adb0
D4-7: 01000000 00200000 00000000 00000001
A0-3: fffffa1d 00e0052e 00e09cde 00e0923e
A4-7: 4000230c 20000020 00000ffc 00000f5a
 USP: 7fffffff

Any ideas? It would be very much appreciated

[sety]

Code: Select all

A4-7: 4000230c 20000020 00000ffc 00000f5a
 USP: 7fffffff  <-Wait, wtf?  Is this normal?
 

I'm no programmer, but this doesn't look right. What have I done to this poor, almost working computer?

[PhilC]

@sety humour me with this. take out the ISA cards and clean the edge connectors, do the same with the sockets. Then do the same with the Simms and the 68150.

Most of my issues were because of bad connections. It's also worth trying a new 68150 in case you have a fake like I did? Also what oscillator are you trying to use? 48mhz? maybe try a 40mhz if so, in case your CPU doesn't like 96mhz.

[sety]

Most of my issues were because of bad connections. It's also worth trying a new 68150 in case you have a fake like I did? Also what oscillator are you trying to use? 48mhz? maybe try a 40mhz if so, in case your CPU doesn't like 96mhz.

I'm just using whatever was on the BOM, so I think it's 40Mhz?

I've ended up with a few bus terminators, I have a freescale and a motorola 33Mhz, and a freescale 40Mhz, but that one never works. The others work okay. I'll swap them out again, but I don't have a PLCC puller, so I need to be real careful

[agranlund]

That USP does look odd, but then again I'm not sure if EmuTOS is supposed to have initialised it before that stage or not. It won't be running any usermode code until a bit later on.


Since it hasn't printed the result of the delay calibration I'm thinking it probably dies in there.
That code is sets up and counts TimerD interrupts over a number of loops.

You're getting an exception 100 which doesn't make any sense. There wouldn't be a service routine for that on a non-TT machine so that's probably why it crashes.

However, 100 is only a single bit different from a timerD interrupt (68) and given where we are in the code it seems like that could be a decent lead:

Code: Select all

01100100 : 100 : bogus interrupt
01000100 :  68 : timerD interrupt
  ^

The MFP is responsible for placing the interrupt number on the data bus D0-D7 so possibly
PD21 (mfp<->68150)
BD5 (68150<->buffer)
D5 (buffer<->cpu)

My gut reaction would be to double check for shorts on U103/U106 but the suspected bit doesn't seem to be adjacent to something that would force it high.
PD21 is routed to a bunch of stuff though and maybe the issue is there. I would get rid of things if you have them and see if anything makes a difference (cf card, isa cards)
A slower oscillator could be a good test too, in case your 68150 isn't entirely happy overclocked to 48mhz.
(not all frequencies will work but I used to go to a 25mhz one for debugging and PhilC has been using a 40 successfully)