Granlunds FrankenSTein

Blogs & guides and tales of woo by forum members.
User avatar
PhilC
Moderator
Moderator
Posts: 3664
Joined: Fri Mar 23, 2018 8:22 pm

Re: Granlunds FrankenSTein

Post by PhilC » Wed Sep 09, 2020 6:06 pm

@agranlund nicely done.

Itd be good to knock up a small pcb to adapt the cable etc. I'm happy to do this if I can get a small schematic of the 74 chip etc.

BTW, the firmware I used is the version before @terriblefire did the 64mb bus error and ide fix, so maybe when he gets time he could readd the bus error to that and we can happily use the adaptor pcb for ide?
If it ain't broke, test it to Destruction.

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Wed Sep 09, 2020 6:48 pm

PhilC wrote:
Wed Sep 09, 2020 6:06 pm
@agranlund nicely done.

Itd be good to knock up a small pcb to adapt the cable etc. I'm happy to do this if I can get a small schematic of the 74 chip etc.

BTW, the firmware I used is the version before @terriblefire did the 64mb bus error and ide fix, so maybe when he gets time he could readd the bus error to that and we can happily use the adaptor pcb for ide?
Oh, I didn't know there was a firmware that fixes the mem detect.
It probably makes sense for me to flash that version to my card so I don't have to run a custom EmuTOS with terrible hacks in it :)
What was the IDE fix in that version?

Sounds like a good idea with a small adapter board. I made one to relocate and byteswap the CF adapter for the TF534 and it made everything very neat and tidy without need for cables :)

The way I have it hooked up is that I ran a wire from pin31 of the CF adapter to pin31 on the IDE connector of my blitter board (which is already tethered to ACSI10). The schematics, eagle etc for that board is here, the IDE part is just an exact copy of P.Putniks IDE interface:
http://www.happydaze.se/stblitter/

But the part you are interested is just this little bit though:
That 74LS03 is just being used as a NOT gate to invert the IRQ signal.
irq.png
irq.png (17.01 KiB) Viewed 539 times

User avatar
Umberto1st
Posts: 95
Joined: Wed Sep 27, 2017 6:27 pm

Re: Granlunds FrankenSTein

Post by Umberto1st » Wed Sep 09, 2020 7:19 pm

agranlund wrote:
Wed Sep 09, 2020 6:48 pm
PhilC wrote:
Wed Sep 09, 2020 6:06 pm
@agranlund nicely done.

Itd be good to knock up a small pcb to adapt the cable etc. I'm happy to do this if I can get a small schematic of the 74 chip etc.

BTW, the firmware I used is the version before @terriblefire did the 64mb bus error and ide fix, so maybe when he gets time he could readd the bus error to that and we can happily use the adaptor pcb for ide?
Oh, I didn't know there was a firmware that fixes the mem detect.
It probably makes sense for me to flash that version to my card so I don't have to run a custom EmuTOS with terrible hacks in it :)
What was the IDE fix in that version?

Sounds like a good idea with a small adapter board. I made one to relocate and byteswap the CF adapter for the TF534 and it made everything very neat and tidy without need for cables :)


The way I have it hooked up is that I ran a wire from pin31 of the CF adapter to pin31 on the IDE connector of my blitter board (which is already tethered to ACSI10). The schematics, eagle etc for that board is here, the IDE part is just an exact copy of P.Putniks IDE interface:
http://www.happydaze.se/stblitter/

But the part you are interested is just this little bit though:
That 74LS03 is just being used as a NOT gate to invert the IRQ signal.
irq.png
Your the man, Will try this fix this evening. So any ttl inverter should work?
3)1040 stf/m, 2)Mega 4 ST, 1)STE, 1)Mega STE, 1)STacy, 2)Falcon 030

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Wed Sep 09, 2020 8:28 pm

Umberto1st wrote:
Wed Sep 09, 2020 7:19 pm
Your the man, Will try this fix this evening. So any ttl inverter should work?
As long as it's an open collector variant I'm assuming it should be fine. ACSI10 is being pulled up on the Atari side and you want to pull it low when IDE_IRQ outputs high.

I'm more of a software guy though so take anything I say about hardware with a grain of salt :lol:

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Thu Sep 24, 2020 2:26 pm

Having fun modifying TOS2.06 with the goal of making it "just work" out of the box with the TF536.
I'm basically just compiling in the TT-RAM, cache & MMU related stuff from 3.06.
Oh, and modified the IDE code to no longer rely on that wire to ACSI pin 10.

It boots to desktop from the untethered IDE interface, and the fastram is detected and taken advantage of without any outside help :yay2:

Thank you @thorsten.otto! I'm using your source package and had no issues at all building the TOS image from inside Hatari :)
_20200924_145329.JPG
_20200924_145329.JPG (179.34 KiB) Viewed 407 times
I'm not saying a custom TOS is the way to go, the original does work with cache disabled, a bit of help from maprom.prg/fastram.prg, and a wire to ACSI10 after all. Also, I'd argue EmuTOS is a much better option anyway.
But for fun, I'm going to keep playing around with this - I like seeing the 64MB TT-RAM detected on the Atari bootup screen :D

Left to do:
- Bring over the cache flushes from 3.06, this should make it stable even with cache enabled.
- Make sure it can still run on 68000/no-mmu/no-ttram setups.
- Stress test IDE

User avatar
exxos
Site Admin
Site Admin
Posts: 12319
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: Granlunds FrankenSTein

Post by exxos » Thu Sep 24, 2020 2:36 pm

agranlund wrote:
Thu Sep 24, 2020 2:26 pm
I'm not saying a custom TOS is the way to go, the original does work with cache disabled
What was the issue with the caches then ? I am not turning it off here, but I am not running any software at all either currently.. just TOS206...
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Thu Sep 24, 2020 2:50 pm

exxos wrote:
Thu Sep 24, 2020 2:36 pm
agranlund wrote:
Thu Sep 24, 2020 2:26 pm
I'm not saying a custom TOS is the way to go, the original does work with cache disabled
What was the issue with the caches then ? I am not turning it off here, but I am not running any software at all either currently.. just TOS206...
2.06 doesn't flush it with DMA and Blitter operations so you could end up reading stale data.

For example, this scenario where something is read from floppy to Altram:
1) data is DMA'd to the FRB located in ST-RAM
2) cache is flushed (TOS 3.06 and higher)
3) contents of FRB is cpu-copied to destination in Altram

The cache flush is important here to make sure data is actually re-read from the FRB rather than potentially being grabbed from a stale cache if you are unlucky.

There are other scenarios too. The safest option is to disable cache in TOS2.06

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

Re: Granlunds FrankenSTein

Post by thorsten.otto » Thu Sep 24, 2020 3:19 pm

agranlund wrote:
Thu Sep 24, 2020 2:26 pm
Thank you @thorsten.otto! I'm using your source package and had no issues at all building the TOS image from inside Hatari :)
Always glad to be helpful ;)

Note that it is much more comfortable to compile it on linux, using the cross-compiler of alcyon. That compiles the whole package in about 4sek on my machine.
Also, I'd argue EmuTOS is a much better option anyway.
Yes, i agree. EmuTOS will have some incompatibilities with games (not EmuTOS' fault 99% of the time), but TOS 3.06 won't work in most of these cases, either. And with EmuTOS you have a builtin disk driver.
Bring over the cache flushes from 3.06, this should make it stable even with cache enabled.
EmuTOS should do that too, if a 68020+ is detected.

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Thu Sep 24, 2020 3:54 pm

thorsten.otto wrote:
Thu Sep 24, 2020 3:19 pm
Note that it is much more comfortable to compile it on linux, using the cross-compiler of alcyon. That compiles the whole package in about 4sek on my machine.
Ohh, thanks for the tip I'm going to try that!
It takes a little bit more than 4sek inside Hatari :D

User avatar
agranlund
Posts: 363
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Granlunds FrankenSTein

Post by agranlund » Thu Sep 24, 2020 11:24 pm

@thorsten.otto , I grabbed the latest source package and it seems to be missing a whole bunch of tospatch related stuff.

was missing: common/patchdef.h, common/nopatch.h & common/localconf.h
So I created empty ones just to get it to continue.
(I assume all the missing TP_xx defines I get warnings about probably originates from the missing patchdef.h?)

Likewise, the file "tospatch/fuji/atari.s" included by bios/startup.S is not there so I commented out the include and pasted in the logo data from startup.S off the much older package that didn't know anything about tospatch.

At the next compile error I figured I should just call it quits and reach out for help before I go back to the (much) older package again :) Am I missing some other download perhaps?

Post Reply

Return to “MEMBER BLOGS”