Fixing Blizzard 1260

When we first tested a (borrowed) Blizzard 1260 with the A1100 it didn’t work. It’s been a long research until we found out what the cause was and how to fix it with minimal intervention.

The root cause

The starting point seems obvious: It must be one of the differences between the A1100 and the original Amiga 1200. First come to mind the difference of the AGA chipset but I didn’t think that a pure accelerator like the Blizzard needed AGA so I suspected of the bus width of the rom area (16 bit on the A1100 vs 32 bit on the 1200).

The bus width is implemented fully legal and is well stated during the bus cycles by the A1100 logic so something in the blizzard must be out of spec (even if it goes unnoticed on the original 1200). That may have been the end of the story as it’s burnt in the bus translator (a cpld) in the blizzard and can’t be fixed, but quickly some increasing signs of hope became visible:

• The blizzard did the rainbow effect at bootup and failed LATER, with a yellow background. The led did some flashes and then the amiga restarted in an endless cycle. So the cpu was working and it accessed the blizzard bootrom, the custom chips and the cias ok.
• The amazing John Hertell’ DIAGROMs worked directly and reported both the 060 and the fast ram without any problem.
• Every kickstart showed the early alert/restart after the rainbow EXCEPT the old 1.3 kickstart (I had just fixed the memory map issue which prevented 1.3 from working. Yes, it works now). The 1.3 booted with no problem with the 060 and the fast ram. That was unexpected and opened great expectations!

There was a problem with the rom access but It worked with a diagrom or an old kickstart. The problem showed only when a 040/060 aware code in the kickstart activated the cpu features. If not touched, everything worked ok.

My guess is that the wrong access is probably a 060 burst access which the bus translator logic directly translates to a 32 bit access in the 020 bus, but it doesn’t listen to the bus width reported and thus the access is not split. It must happen only when the originating mode is burst (which is implied with cache enabled unless the control glue cpld asserts the TBI signal to inhibit the burst in that memory area).

So, the blizzard probably doesn’t inhibit burst for rom area (which is correct for the 1200, but doesn’t give any benefits because the burst can’t be done in the amiga side).

Why this was good news

All blizzard cards have a built-in maprom feature which hides all rom accesses and perform them in local fast-ram which provides really good performance. So, no rom access to real amiga roms (in performance mode) with maprom and, when cache is off, normal access with no errors (to start booting and during rom copy for maprom). No problem!

After making sure then maprom was enabled and it still failed, the knightmare begun.

How it all fits together?

We already know that the blizzard manages to work ok without cache enabled and performs ok with 1.3 so start old skool asmone and start hacking!

The blizzard uses two different, sequential, mechanisms to boot the amiga:

• A ‘cartridge’ rom (the bootrom) with does the rainbow effect and allows you to disable it all and reboot in 020 mode pressing the 2 key
• A bussiness usual Autoconfig rom which (later) adds the fast-ram to system AND enables the maprom feature copying the rom to fast-ram during the expansions enumeration.

Both feature roms are directly readable and the embedded code is very small.

After further investigation some details were found:

• The bootrom disables de 060 fpu (to make the stack frames compatible with the 040, so standard system software have no surprises) and then checks the 2 key press during the rainbow effect. If you press the key, it does some f-space magic which disables the accelerator completely until next power on. Otherwise, it does nothing more.
• The autoconfig does a lot of calculations to measure the amount of ram installed and then reserves half megabyte at the end (at a fixed address) for the rom copy. Then makes another f-space trick to enable the map rom (or something) and adds the remaining memory to the system.

All this operations work ok with the 1.3 rom, even if you activate the cache AFTERWARDS. So the maprom saves us by avoiding burst access thru the bus translator when we enable the cache, and we run at full speed. We are lucky!

Whatever the newer roms do which makes boot fail, I would hopefully be able to check it tweaking the copy in the local fast-ram (which is run as rom at boot) and figure the problem, but…

The maprom doesn’t love me

I spent more than a week checking the kickstart code and testing fixes but I was unable to boot the modified rom reliably. I tested blizkick (which unexpectedly didn’t work) and I even tried to get some of the code of it and modify it with no luck.

I had to use a “fake” boot, actually jumping to the rom without performing an actual reset. Using this trick, as soon as I fixed the kickstart mmu code to disable both instruction and caching to the low 24bit area (it does it only for data) the kickstart 3.1 finally booted again, but without fast-ram.

Until I was able to perform an actual reset to re-enable autoconfig on the blizzard I would not get memory added to the system, or the f-space magic (which I still don’t know if it’s needed after every reset. More on this later). The hack didn’t survive a reset so I couldn’t just press reset to get it all ready.

In the process I added my asmone code to perform arbitraty patches in the kickstart with code directly in the same source file so It was really easy to test hacks. I finally gave up of actually rebooting with a patched kickstart. I suspect this card logic has a small “bug” (only for soft kicking) that disables the maprom feature upon reset until re-activated on next autoconfig enumeration. It doesn’t happen cleanly so it just crashes if the roms and the copy in maprom memory don’t match. Sad, so I went back to figure the details of the boot process just watching the code.

We needed a patch

The code in the first lines both of the kickstart and the blizzard bootrom is quite dirty because there is still no system, but after figuring the code expected preconditions and the actual environment I found some incoherencies:

The boot rom (a cartridge rom, as seen by the amiga kickstart) was called with rom overlay (an every amiga model feature which overlays the kickstart rom over the lower addresses of chip ram after reset) still enabled, but the bootrom used the lower addresses as ram (tweaking the vectors). I still don’t know if this causes real damage but I re-ordered the code to perform very basic hw (customs chips and cias) initialization (which disables overlay) and directly follows the cartridge call, to happen BEFORE the cartridge call.

Later, upon the cpu detection, the transparent translation register allowed instruction caches in all memory and relied on the accelerator logic to behave correctly with non-cacheable areas (such as chip-memory or real hw registers). That was needless calling for trouble and probably causing the crash as soon as the cache was active. It’s not needed because the real environment for a 060 is made later, after disk is booting, by setpatch command that, and in the case of the 060 loads your prefered 68060.library and does a lot of things.

I just left the instruction cache enabled for local accelerator fast-ram, over the 24bit memory area. This allowed the patched rom to perform correctly to the blizzard enumeration without problem and complete the boot process without losing any of the original features and using the fast maprom of the blizzard for full-speed, saving the day. The patched kickstart is tested with the 020 cpu too and works exactly as before.

So, the blizzard 1260 finally runs ok with the A1100