exxos's Atari, Amiga & retro forum

Hello all,

I've been trying to find the source code for the TF536 for something I'd like to experiment with. I've found the github repo for the TF1230, as well as the one which contains pre-compiled binaries for several cards. I've seen mentions on the forum about custom firmware versions, but haven't been able to find the actual source code to be able to create such a thing. Is it actually available online?

I'd like to play around with trying to get Zorro 2 expansion cards working again under Kickstart 1.3. Before I got my TF536 I had created a nice dual-boot setup with KS 1.3 and 3.2. I understood before getting the card that a lack of Zorro 3 support would mean I wouldn't get the onboard 64 megs of RAM working under KS 1.3, and that I wouldn't get the IDE working without hacking-in a suitable scsi.device. However, I didn't realize that I would also lose access to the Z2 cards in my system which means I don't have my Z2 RAM or (more critically) my Xetec SCSI card when booting 1.3.

I'm assuming (based on the lack of /CFGIN pin on the CPU slot) that the Z3 RAM must be placed first in the AutoConfig chain, and the TF536 presents that to the bus first before then selecting the first card in the "real" AutoConfig chain. I'm therefore speculating that the lack of Z3 support in KS 1.3 means this first step never happens, and the Z2 AutoConfig chain is effectively masked.

I saw terriblefire mention the possibility of a hacked version of KS 1.3 existing with Z3 support. I've been searching for one but not found it. I've also been trying to create my own ROM which could work (mostly looking at trying to get the A3000's KS 1.3 to work, as the bonus code for that does seem to enable Z3). While I have been able to get the 1.4 ROM working (by removing the incompatible scsi.device), I haven't got the 1.3 superkickstart image to work because I don't have a way of editing the bonus code to remove scsi.device from that. So the custom ROM idea hasn't gone anywhere.

I think the last thing I can try is adjusting the behavior of the card itself. I was hoping to take a look at the source code, firstly to confirm my theory about how the AutoConfig is working and second to see if I could create a switch to disable the Z3 AutoConfig and restore the original Z2 AutoConfig behavior. I'm not using CDIS or MMUDIS right now, so I was hoping to repurpose one of these as "RAMDIS" or similar.


I know KS 1.3 is untested, unsupported and unwise. I know there's very little technical reason to actually run 1.3, and WHDLoad should take care of most compatibility concerns for me under 3.2. Right now the only reason I want to try and make this work is purely to conquer the technical challenge and see if I can restore the work I'd previously put into the dual-boot. I'm not looking to take up anyone's time with such a strange and niche request, but if I could get access to the code to try and solve it myself then that would be great.

Thanks in advance to anyone who can point me in the right direction!

Alex

Sorry but this will never be released. The TF cards are not allowed to be modified either in firmware or on the PCB downstream. Thats the license.

Basically this is my art. You can reproduce it but you cant modify it.

OK, I respect that. Thank you for responding.

Can you tell me if you think I might be on the right lines with my belief that a lack of Z3 support is also what's causing the Z2 cards not to successfully AutoConfig? Is that the right thing to keep working on from a software point-of-view?

Thanks again.

Alex Oughton wrote: 27 Nov 2022 01:47 OK, I respect that. Thank you for responding.

Can you tell me if you think I might be on the right lines with my belief that a lack of Z3 support is also what's causing the Z2 cards not to successfully AutoConfig? Is that the right thing to keep working on from a software point-of-view?

Thanks again.

That is correct and its exactly why Kick 1.3 is completely not supported on the TF536. You can patch a more modern expansion.library into kick1.3 maybe.

Great, thank you. I think I tried just directly replacing expansion.library in the past and not getting very far. This might just not be possible, and I'm willing to accept that. But only after wasting far too much time on it, because the hacking is fun. :-)

Alex Oughton wrote: 27 Nov 2022 01:59 Great, thank you. I think I tried just directly replacing expansion.library in the past and not getting very far. This might just not be possible, and I'm willing to accept that. But only after wasting far too much time on it, because the hacking is fun. :-)

Having the TF536 sourcecode wouldnt help you in any case. The TF card needs to be 1st in the chain and it needs to be ZIII as its a size not supported by ZII.

What you could do it look at the A3000 / Bigram docs and find the ZIII autoconfig example. It was meant to be used on 1.3 for configuring ZIII cards before OS 2.0 was out (from memory, there may be holes in my memory) I cant remember where it is but you could run that code post boot to get the RAM and cards configured. Or put that code in your own little library and burn your own rom. I'm pretty sure someone must have already solved this.

The code you're looking for is in the last 4 pages of this PDF.
EDIT: Actually this wont work as is because although the TF card is a ZIII card its configured at the ZII location (0xE80000). A500/A2000 kickstarts dont even look at the 0xFF000000 location. Basically you need code to configure the TF card then poke exapnsion.library to finish configuring the config chain.

Thank you again! I'd seen discussion around this PDF before, but the links were broken. I'll study what's there, as well as your note about configuring at 0xE80000. Perhaps as you suggest I can use this to introduce a small library to initialize the TF536 before expansion.library gets called.

@terriblefire Thanks again for the pointers so far. I've actually got pretty far in getting the source code from the PDF to work (most of the work so far has been in figuring out and correcting typos in the original document). I've got it properly reading the AutoConfig ROM from the TF536 and it's successfully configuring the card in both the board list and the memory list. So far so good.

However, the TF536 still isn't "letting go" of 0xe80000, so the next iteration through the loop tries to add the same board again (which will crash the system if I allow it to complete the process). As I understand the documentation, I should expect this to happen once register 48 gets written with the assigned address. Assuming my understanding is correct, I believe something to be wrong with the WriteCfgAddr function in the code.

I'm particularly suspicious of this line (why is 22 decimal what we're adding here??): https://github.com/alexoughton/configz3 ... gz3.c#L174

To give a sense of what's happening during this function, the debug output from my edited code is reading as follows:
Those address are strange to me. I tried hard-coding it to something which I thought made sense instead (0xe80044), and also tried just writing dummy values to 0xe80048. Both ideas crashed the system.

I'd appreciate any thoughts you might have here! Thanks again.

I mean it absolutely does let go of the autoconfig otherwise it wouldnt work with the A570. Which it does.

My autoconfig code is pretty much identical to here..

https://github.com/terriblefire/tf1230/ ... toconfig.v

You should be writing in the 0xe8004x range as this is the "write register" area.

EDIT: I'd strongly recommend getting your code/setup working on WinUAE with 64Mb of ram before asking TF536 specific questions.

Oh yes, I know it lets go when it's configured correctly as my SCSI card works just fine with the TF 536 under WB 3.2. There's something wrong with this code though as it's not triggering that behavior correctly. I've been reviewing that autconfig.v file, and that's why I thought just writing any dummy value to the register would work (if I read it correctly, any kind of write there will set "configured" and therefore "cfg_out").

I haven't worked in C since about 2005 or so (and then only rudimentary stuff), so I'm pretty much just "hacking" at this until it works. I think I'm on the right lines to say that the code is making bad decisions about where the write address should be, so I think I'll just keep working on that. There's probably some over-complexity here due to their provisions for Z3-in-Z3-space (which will never happen here). I may be able to get things working just by simplifying it a bit and hard-coding the correct addresses.