• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Wombat (650, 800) board overclocking limitations

trag

Well-known member
@jessenator I finally loaded the software and started using my TL866II+ and I even read the manual all the way through. Gasp.

Sadly, the Xgecu software does not include a feature to deinterleave a wide .bin file for programming on narrower chips. For example, you have a 32 bit wide ROM file for the Wombat and need it deinterleaved across 4 8-bit wide Flash chips.

You'll need to write some kind of program or script to do that yourself as a separate step.

It shouldn't be difficult, but it is another step.
I was wrong about this. The feature is "hidden" in the Load File box. When you load a file to the buffer a options box comes up and one of the pull downs on the right side of the box let's you load "first byte of two byte word" or "third byte of four byte word".
 

demik

Well-known member
Gotcha.

Do you have a workflow/script already in place for that I might be able to use? I don't trust myself to actually write anything that would actually, y'know, work : P

Yes ! You may want to use an utility such as srec_cat:

Code:
> srec_cat quadra.ROM -binary -split 4 0 -o U4.bin -binary
> srec_cat quadra.ROM -binary -split 4 1 -o U3.bin -binary
> srec_cat quadra.ROM -binary -split 4 2 -o U2.bin -binary
> srec_cat quadra.ROM -binary -split 4 3 -o U1.bin -binary

Since the Wombat ROM is only 1MB, it's a good practice to "duplicate" the ROM contents (the GG Labs is 2MB as the Quadra 840av ROM)

Code:
> cp U1.bin U1d.bin && cat U1.bin >> U1d.bin
> cp U2.bin U2d.bin && cat U2.bin >> U2d.bin
> cp U3.bin U3d.bin && cat U3.bin >> U3d.bin
> cp U4.bin U4d.bin && cat U4.bin >> U4d.bin

Now you should have 4 512KB files, one for each chip. Burn them with minipro or something else:

Code:
> minipro -w U1.bin -p 'SST39SF040@PLCC32'
> minipro -w U2.bin -p 'SST39SF040@PLCC32'
> minipro -w U3.bin -p 'SST39SF040@PLCC32'
> minipro -w U4.bin -p 'SST39SF040@PLCC32'

I can't remember if I had to swap U4 and U1 and U3 and U2. Tell me how it goes !
 

jessenator

Well-known member
Tell me how it goes !
Will do!

I'm still putting off desoldering the filled through-holes on an actual Wombat board, even though I've practiced (with a dead 4400 board) enough to feel okay with moving to a working one.

I've got my ROM socket ready to go, so that's my last excuse for not moving ahead : P
 

jessenator

Well-known member
This week has been kind of crazy and the weekend has had little 'rest' in it. I'll hopefully have some time this coming week to get the socket installed, flash the ROM code and give it all a try.
 

cy384

Active member
This evening I desoldered the ROM socket holes for my mobo, as I have the connector and ROM SIMM coming in this week. There's another trick/technique that nobody has mentioned: solder doesn't stick to pencil lead (graphite). This wouldn't help for normal desoldering where there's a pin or something in the hole, but it works quite well here.

Get a cheap plastic 0.7mm mechanical pencil, extend about 5mm of lead. Mount/brace your PCB vertically somehow. Push the pencil at the hole from one side, and then melt the solder on the other side. It will pop through pretty quickly and then you can take the heat away. Carefully pull the pencil back and try not to break the lead (you will at least a few times, have a needle or something to poke it out). It's pretty quick and easy once you get the hang of it. Keep in mind you don't need to get rid of all the solder, just make a clear path for the socket's pins to go through.

I used 1.1mm lead (used for vintage pencils but probably not worth buying just for this) for the larger holes on the ends/middle.
 

trag

Well-known member
@cy384 I've used that exact method to clear empty (but for solder) holes. Except I used a stainless stick pin with a plastic bulb on the end.

The solder rarely sticks to the pin, and the tiny plastic knob on the end protects one's fingers from the metal pin head which can get hot. It has the advantage that it doesn't break, but it's probably not as ergonomic as a pencil. The pencil gives one a nice handle for the pokey bit.
 

cy384

Active member
Ok, I have some good news and some disappointing news.

Good news: got the socket soldered on, the SIMM programmed, and it seems like my latest ROM hacks with "always 40MHz" settings works, and boots successfully with a 22MHz oscillator.

rom.jpg

Disappointing news: I immediately popped in a 25MHz oscillator. It consistently starts to boot (which is a big improvement), but hangs early on at this screen. Note the video artifacts:
artifacts.jpg

My suspicion is that it's waiting for some piece of hardware to communicate, but it times out. It does manage to load the OS, so at least SCSI is working. Also I apparently left my 24MHz oscillators at my parents' house, so I won't be testing that speed until I visit them in two weeks or so.
 

jessenator

Well-known member
My suspicion is that it's waiting for some piece of hardware to communicate, but it times out.
how's the heat coming off your SCC, IOSB, and KIWI?

sorry I've been lax in keeping up with everything : / work and life have been keeping me busier than I predicted. When I get some time and gumption, I'll test mine on 24/48 and see if that manifests. I suppose I'll have to check if my ROM flashing works first, heh.
 

cy384

Active member
I was depressed about this, but on my lunch break decided to try booting again (excuse the giant pic, on my phone and can't resize)
2021-10-06_12-10-24~2.jpg
 

jessenator

Well-known member
decided to try booting again
e3KaKTY.gif
vzxgtVy.jpg
 

cy384

Active member
I tried again a few more times without success, but it did run for a little while! I guess 48-ish MHz is the real limit of the hardware. It's clear that the video hardware, at least, is at its limit. So, here's some possibilities:

* some other hardware config registers aren't set right for these speeds (poke around in the ROM some more?)
* VRAM is too slow (possible to find faster chips? maybe, maybe not)
* video chips are too slow (have to develop new video chips and driver, not practical)
* other chips are too slow (needs debugging to figure out where exactly the OS is getting stuck during boot)

From here I'm going to spend a little more time messing with djmemc config values, explore the ROM source a little more, and then focus on improving bbraun's 64MB/128MB SIMM support.

Even if 50MHz doesn't end up being stable, I'm reasonably satisfied.
 

cy384

Active member
There's some code in "DepVideoEqu.a" which I think is configuring the video hardware, and there's some stuff like "dafb40MHzConfigW" which seem frequency related and may solve the video problems, if I can figure out how to actually patch that part of the ROM. It seems like this may be one of the parts of the ROM code that changed a lot in between the C650 release and the leaked code. Really hard to figure out what's going on!

As an aside, the Quadra 660av/840av ROM won't boot my C650 (makes a weird chime and fails before putting up a progress bar).
 

trag

Well-known member
VRAM chips are available at least down to 60ns. I'm not sure if 50ns is available.

One test method is to get some coolspray and try booting while gently spraying the chip you want to test. If it works while you're spraying it and doesn't work when you're not, that's probably the location of the constraint.

Of course, if more than one component is constraining the system, then this method of testing is much more fraught.

Still, fantastic work.

Is it possible that any of the settings you're adjusting are changing the wait-state for RAM operations? IIRC, the RAM chips on the logic board are usually 80ns. If DRAM timings are being changed in the ROM, then you may need to go to faster chips.
 

cy384

Active member
I just got a 23MHz oscillator (seems like I'm collecting the full set, huh). It will consistently boot to 46MHz with no video problems (with my latest ROM, with only djmemc speed/config changes) but only with extensions disabled.

Unfortunately, it seems like networking won't operate above 44MHz. OpenTransport extensions, Appleshare, Appletalk, the built-in ethernet extension, and basically anything else network-related cause it to hang on boot. Disabling those seems to result in a stable system otherwise. I'll note that I'm running OS 8.1.
 

jessenator

Well-known member
Unfortunately, it seems like networking won't operate above 44MHz. OpenTransport extensions, Appleshare, Appletalk, the built-in ethernet extension, and basically anything else network-related cause it to hang on boot.
Exactly the wall I hit : / (also in 8.1)

I wonder then if we are overdriving the 8 MHz SCC (it's certainly getting hot with the stable speeds). And wondering, too, if with a faster one there might be a way to still have serial/AT/TCP/IP...
 

Mr. Ksoft

Well-known member
Weird, my networking still worked at 45mhz, though as I mentioned serial didn't. Definitely marginal at that speed though.
 

cy384

Active member
Weird, my networking still worked at 45mhz, though as I mentioned serial didn't. Definitely marginal at that speed though.
I'll admit I didn't test 45, just 44 and 46.

Just added bbraun's large SIMM support (one line change in a part of the ROM I already disassembled), just got it going with a total of 264MB (128, 128, and 8 onboard). I'm a little concerned about how this actually works, I guess the 8MB gets detected/set up separately from the other RAM somehow? I need to spend some time to finish disassembling and understanding how the RAM sizing works.

big-ram.jpg

Edit: If I add any more SIMMs (tested with 32MB and 128MB, all I have at hand) it fails to boot and gives the sad chimes.
 
Last edited:
Top