The ST TF536 software compatibility list.

All about the ST536 030 ST booster.
User avatar
stephen_usher
Posts: 5580
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: The ST TF536 software compatibility list.

Post by stephen_usher »

Yeah, after I posted I realised that the other big change is the video sub-system.

Really what we need is a merged 2.06 and 3.06 build, sort of 2.56. :-)
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: The ST TF536 software compatibility list.

Post by thorsten.otto »

stephen_usher wrote: Thu Oct 08, 2020 11:51 am Really what we need is a merged 2.06 and 3.06 build, sort of 2.56. :-)
That is essentially what the PAK patches do, using TOS 3.06 (because it is 030 aware), but patch out the TT video modes.

BTW the VDI of TOS 2/3 also uses self-modifying code (well not really "modifying", small routines are created on the stack). TOS 3.x flushes the cashes for this, TOS 2.x doesn't.
User avatar
PhilC
Moderator
Moderator
Posts: 6016
Joined: Fri Mar 23, 2018 8:22 pm

Re: The ST TF536 software compatibility list.

Post by PhilC »

@thorsten.otto do you think the paj version of 3.06 should work as is then?
If it ain't broke, test it to Destruction.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: The ST TF536 software compatibility list.

Post by agranlund »

Yeah you could start in either end. Either with 3.x and remove/replace TT-specific bits or start from 2.x and add in the 030 specific stuff that's incomplete (built in fastram support, setting up the mmu, fixing the 030 caching issues comes to mind)

3.x assumes TT video hardware as mentioned. I don't know if it assumes DMA sound and will freak out when this does not exist - if so that needs to go as well.
There's probably other bits of hardware it assume is always present.
Blitter code is not present on 3.x so if you want that you'd need to lift it from 2.x (may as well incorporate what Blitfix is doing so TOS can safely use it in the presence of TT-RAM :))
And you need a TOS decoder and a rom board that is compatible with 512Kb roms.


If it weren't from the PAK patches I would personally go for fixing up 2.06 for these reasons:
- Probably less work adding the missing bits than making 3.06 work on non-TT hardware.
The TF536 runs well on 2.06 already as long as you disable the cache, but it would be nice if that was fixed, and also if it detected fastram without needing support programs in the AUTO folder.

- You're starting with a working build making it easier to add features and see when it breaks, as opposed to starting with a non-booting build and hacking away TT specific stuff until it hopefully boots at least.

But since all the hard parts were already done with the PAK patches, maybe it is a lot easier to start from PAK 3.06 and adjust anything that may need adjusting for working on the TF536?
Maybe PAK 3.06 actually just works as is?

Edit: I'm also genuinely interested in why you would want to build a new hybrid TOS 2/3 unless it was a moderate-effort, or for fun and learning, type of thing. Don't get me wrong, I enjoy fiddling with the 2.xx sources myself to try and make it behave a little better, but where does it end though?
You'd probably also want to give it a better built in IDE driver so it can boot from any device number with or without twisted cable, after that maybe some other new features.
At what point does it become reinventing the same wheel as EmuTOS? :)
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: The ST TF536 software compatibility list.

Post by exxos »

agranlund wrote: Thu Oct 08, 2020 3:44 pm Maybe PAK 3.06 actually just works as is?
I know its been asked before.. Though IIRC I verified @Darklord PAK 030 TOS with proper TOS and it was the same.. Though I know I did the same with my PAK but it was a 020 version which came from @frank.lukas . I think Darklord thought it was patched but it actually wasn't.. but can't remember now exactly as was years ago.. maybe someone with pak030 306 can just verify if its the same as generic 306 or not...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
stephen_usher
Posts: 5580
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: The ST TF536 software compatibility list.

Post by stephen_usher »

Given that 2.06 is designed for the STE which has the same sound hardware as the TT that shouldn't be the issue.

I doubt that PAK has the second MFP or the Zilog SCC or the SCSI chip that'll probably be close to the TF536 in hardware terms.

I can hack my relocator/ROM board to handle 512K ROMs, just add A17(?) to control which end of the ROM it's looking at and change the GAL code slightly should do the trick. (This assumes that the board works of course!)
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: The ST TF536 software compatibility list.

Post by agranlund »

stephen_usher wrote: Thu Oct 08, 2020 4:05 pm Given that 2.06 is designed for the STE which has the same sound hardware as the TT that shouldn't be the issue.
You are probably right in this case but I wouldn't assume anything when it comes to TOS :lol:
Worst case they figured the detection code was redundant and made it always use a specific hardware they knew TT's would have.

TOS2.06 is the most flexible since it can run on different hardware configurations. This one does detect stuff that are different between ST/STE.
But as an example, blitter code was removed from TOS3.xx since there are no blitters in TTs.
Likewise, TOS4.xx only has blitter code, and they actually removed the non-blitter fallback code.
TOS2.06 detects the presence of the blitter and has fallback blitting code for when it doesn't exist.

I wouldn't be surprised if this mentality was applied to other model specific hardware.
And it probably makes sense since they were fitting the entire OS on ROMs.
User avatar
DoG
Posts: 1125
Joined: Sat Apr 07, 2018 12:26 pm

Re: The ST TF536 software compatibility list.

Post by DoG »

User avatar
thorsten.otto
Posts: 148
Joined: Mon Nov 04, 2019 2:20 am

Re: The ST TF536 software compatibility list.

Post by thorsten.otto »

PhilC wrote: Thu Oct 08, 2020 3:36 pm @thorsten.otto do you think the paj version of 3.06 should work as is then?
No i don't think so. There are some other, PAK specific patches. But a large stuff to get it going are the already mentioned things.
I don't know if it assumes DMA
IIRC, they properly test for its presence.
Blitter code is not present on 3.x so if you want that you'd need to lift it from 2.x
That will be difficult. In an unpatched TOS 3.x, those routines are not only inactive, they are just not there. There are also some other quirks, eg. The "Blitter" item in the desktop menu is changed to "Cache", but there is only one item present, you cannot have both (or you have to patch the desktop as well). Same goes for the general.cpx, it assumes that only one of the two can be present.
Apart from that, the blitter is not of much use on 030, in most cases the CPU will be faster.
Probably less work adding the missing bits than making 3.06 work on non-TT hardware.
Maybe not (except for the blitter stuff). There was a reason i guess why they choose to use TOS 3 as a start ;) Also the 3.x ROMs are already 512k, so there is plenty of room for patches.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: The ST TF536 software compatibility list.

Post by agranlund »

thorsten.otto wrote: Thu Oct 08, 2020 4:26 pm Apart from that, the blitter is not of much use on 030, in most cases the CPU will be faster.
This is true in theory, and certainly for new software that are able to run from fastram and has a render pipeline to take advantage of it while minimising access to video ram.
For old cra... ahmm. things this may not always be true in practice with that 030 being not much faster than an 8Mhz 68000 when interacting with the ST bus.

I ran Gembench with and without blitter and it's only slightly faster with it so it's probably not worth any effort.
Besides, putting NVDI on the system gives you a lot more speedup than the blitter would.

So I guess I agree with you, although technically the 030 is slower than the blitter for how TOS was coded :)
blitcomp.jpg
blitcomp.jpg (45.57 KiB) Viewed 3885 times
Post Reply

Return to “ST536 030 ST ACCELERATOR”