Granlunds FrankenSTein

[PhilC]

@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?

[agranlund]

@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 (17.01 KiB) Viewed 3512 times

[Umberto1st]

@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?

[agranlund]

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

[agranlund]

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

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 (179.34 KiB) Viewed 3380 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

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

[exxos]

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...

[agranlund]

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

[thorsten.otto]

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.

[agranlund]

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

[agranlund]

@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?