Using the Falcon's expansion connector

[dhedberg]

Congrats to the great progress!

[MegaSTEarian]

Looks great, thanks for putting all this work!

How come Alt-Ram and blitter are not working together?

[Rustynutt]

Have either of you guys looked at the delay of the COMBEL clock divider from the 32mhz input to 16mhz output?
Assuming there must be some.
Thanks.

Hi Rustynutt,

Not sure what you're getting at here. Looked at the delay with an eye to what? The delay in me responding to the existing 16MHz clock is of the order 20ns when the clock is 62ns in period, so none of these timing issues apply at the speed the COMBEL is dishing out.

BW

Nothing related, just fishing for data.

[Badwolf]

Nothing related, just fishing for data.

Ah, well I've not measured it, but I'd imagine it's of the order 10ns. Since everything sees the downstream version anyway, I don't think that matters to anything. There is another buffer between COMBEL and the CPU/Expansion/DMA anyway for even more offset.

BW

[Badwolf]

How come Alt-Ram and blitter are not working together?

The blitter is on the motherboard (in the COMBEL chip). Nothing on the motherboard can see AltRAM as Atari used a 24 bit data bus.

See my Wiki.

As to why TOS4 can't be put into my external Flash ROM that's slightly different but similar. The ROM can't be seen by anything on the motherboard, despite not being AltRAM. It does have the appropriate wiring to read the ROM addresses, but the motherboard still has its own on-board ROM. You don't want the blitter reading one ROM but the CPU is reading another!

TOS4 uses the blitter to boot, ergo if you want to use TOS4, it has to be on the mainboard where the blitter can read it rather than on my flash board.

*OR* we have to patch TOS to not use the blitter. This isn't trivial as TOS4, unlike all other versions of TOS, doesn't have any software blitting routines.

Atari really didn't design the Falcon to be expanded, despite it's 'expansion' connector!

BW

[Cyprian]

How come Alt-Ram and blitter are not working together?

The blitter is on the motherboard (in the COMBEL chip). Nothing on the motherboard can see AltRAM as Atari used a 24 bit data bus.

As ALT-RAM we can understand the ram above the ST-RAM (but still in 24bit range). Sometimes the TT-RAM (above 24bit address range) is also called the ALT-RAM.
In the first case, the BLiTTER has an access to the ALT-RAM, in the second case - no.

[Badwolf]

As ALT-RAM we can understand the ram above the ST-RAM (but still in 24bit range). Sometimes the TT-RAM (above 24bit address range) is also called the ALT-RAM.
In the first case, the BLiTTER has an access to the ALT-RAM, in the second case - no.

As far as I'm concerned it's AltRAM in the TT RAM space -- it's registered with a call to "Maddalt". Semantics.

BW.

[Cyprian]

As ALT-RAM we can understand the ram above the ST-RAM (but still in 24bit range). Sometimes the TT-RAM (above 24bit address range) is also called the ALT-RAM.
In the first case, the BLiTTER has an access to the ALT-RAM, in the second case - no.

As far as I'm concerned it's AltRAM in the TT RAM space -- it's registered with a call to "Maddalt". Semantics.

BW.

I know what you mean, in an official documentation the TT-RAM is meant as alternative ram (the ALT-RAM), but I remember that since 90's Atari community uses a different definition - the TT-RAM above 24bit address range, the ALT-RAM above the ST-RAM and below 24bit address range. That was the source of misunderstanding between MegaSTEarian and you.

[Rustynutt]

As ALT-RAM we can understand the ram above the ST-RAM (but still in 24bit range). Sometimes the TT-RAM (above 24bit address range) is also called the ALT-RAM.
In the first case, the BLiTTER has an access to the ALT-RAM, in the second case - no.

As far as I'm concerned it's AltRAM in the TT RAM space -- it's registered with a call to "Maddalt". Semantics.

BW.

I know what you mean, in an official documentation the TT-RAM is meant as alternative ram (the ALT-RAM), but I remember that since 90's Atari community uses a different definition - the TT-RAM above 24bit address range, the ALT-RAM above the ST-RAM and below 24bit address range. That was the source of misunderstanding between MegaSTEarian and you.

I "think" you two are thinking of alt-ram that's present on cards like the Centurbo when talking about the blitter having access to "alt-ram". It's a different address space. That's where my knowledge stops.
The Mighty Sonic, Afterburner and CT60's "alt-ram" or TT-Fast RAM are located at the same address as on the TT.
I'm one of those that calls it both terms.
No blitting there
As I understand.
Not sure why some of the other cards utilized the lower address space, unless they wanted it reserved for another device in the future.

Badwolf, correct me if wrong, you are declaring the same address for your RAM as a TT uses?

I'm just trying to keep up if I have to assemble one of these things

[MegaSTEarian]

As ALT-RAM we can understand the ram above the ST-RAM (but still in 24bit range). Sometimes the TT-RAM (above 24bit address range) is also called the ALT-RAM.
In the first case, the BLiTTER has an access to the ALT-RAM, in the second case - no.

As far as I'm concerned it's AltRAM in the TT RAM space -- it's registered with a call to "Maddalt". Semantics.

BW.

I know what you mean, in an official documentation the TT-RAM is meant as alternative ram (the ALT-RAM), but I remember that since 90's Atari community uses a different definition - the TT-RAM above 24bit address range, the ALT-RAM above the ST-RAM and below 24bit address range. That was the source of misunderstanding between MegaSTEarian and you.

Yup, this is what confused me.
In this case Alt-RAM is actually the "TT-RAM", this means that it should be really fast, right?

Still wondering, since you are keeping the on-board TOS (if I understood correctly), why can't the expansion CPU be seen, or see the on-board CPU, as secondary. This way, the expansion CPU would be working on really CPU intensive tasks where on-board would be taking care of the traffic between custom chips or offload some tasks from the expansion CPU. I understand this takes at least a special firmware on the expansion board at least. Maybe a new TOS version as well. But would EmuTOS or MiNT work?

Well, don't MiNT ( ) my gabbling, here.

[Badwolf]

I "think" you two are thinking of alt-ram that's present on cards like the Centurbo when talking about the blitter having access to "alt-ram". It's a different address space. That's where my knowledge stops.
...
Badwolf, correct me if wrong, you are declaring the same address for your RAM as a TT uses?

I'm just trying to keep up if I have to assemble one of these things

Yes, my AltRAM is beyond 0x00FFFFFF, where the TT keeps its TT-RAM.

However it's not just about address space. It's actually simply about what memory the motherboard (ie. Blitter and SDMA) can address. It can't talk to my onboard ROM, for example, despite that living at 0x00E00000 -- as on the stock Falcon.

So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.

I'll probably have a go at getting EmuTOS to allow blitter down the road (ie. hardware blitting is only used when source and destination are in ST-RAM) -- but it's not a priority ATM.

BW

[shoggoth]

So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.

The TOS4 VDI allows for individual drawing primitives to be replaced fairly easily. You could solve this using a small TSR.

The other option would be to use NVDI.

[Rustynutt]

BW said
[/quote]

It can't talk to my onboard ROM, for example, despite that living at 0x00E00000 -- as on the stock Falcon.
[/quote]
TOS may live at that address, but is it where the system expects to start executing at startup? Guess I should re-read the FSM before asking.
[/quote]
So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.
[/quote]
Is the purpose NOT to use NVDI routines (no blitter)? I mean, that's always been the defacto way. As far as game compatibility (who cares ), simply using ST RAM sufficient set with prg flags, or am I missing something?
Or was the blitter question brought up earlier and I missed it?

Loading TOS into RAM has also been standard practice after booting.
[/quote]
I'll probably have a go at getting EmuTOS to allow blitter down the road (ie. hardware blitting is only used when source and destination are in ST-RAM) -- but it's not a priority ATM.
[/quote]
EMUTOS has come far, but it's not TOS 4.04 IMHO. It's driving far over to the emulator side of things. Was following the dev list, but it got too much into support for features in very low TOS versions that have been traditionally patched to fix. A lot for the sake of just being open source.....

To add insult to injury, MiNT runs much nicer than TOS does now, the only limiting factor using it on a stock Falcon. Your board changes that game

Think you are working the right direction, fast CPU, Fast RAM. Everything else will follow suit as it has the past 29 years

[Rustynutt]

So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.

The other option would be to use NVDI.

Beat me too it

[frank.lukas]

Atari TT has no Blitter so disable the Atari Falcon Blitter.

[Badwolf]

So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.

The TOS4 VDI allows for individual drawing primitives to be replaced fairly easily. You could solve this using a small TSR.

I would if I knew how. I don't (yet) & am worrying about the hardware first.

Also, it uses the blitter from the very first -- to do the Atari Logo on the start screen -- so really it's needs a patched TOS.

The other option would be to use NVDI.

See this post for a benchmark run with NVDI and (on-board) TOS4.

BW

[Badwolf]

Atari TT has no Blitter so disable the Atari Falcon Blitter.

TOS3 doesn't support hardware blitting but does support software blitting.

TOS4 supports hardware blitting but doesn't support software blitting.

So you *can't* turn off the blitter in TOS4. You have to replace the VDI blitting functions (eg. NVDI).

BW.

[Badwolf]

BW said

It can't talk to my onboard ROM, for example, despite that living at 0x00E00000 -- as on the stock Falcon.

TOS may live at that address, but is it where the system expects to start executing at startup? Guess I should re-read the FSM before asking.

My board still has the OS at E00000, it's just that when my CPU access that address it reads from the flash memory. When the blitter access that address it reads from the ROM chip on the motherboard. They get different data.

So, to cut a long story short, hardware blitting can only work where my board does not use any AltRAM and when the booster ROM is disabled. Unless someone patches TOS4 for me.

Is the purpose NOT to use NVDI routines (no blitter)? I mean, that's always been the defacto way. As far as game compatibility (who cares ), simply using ST RAM sufficient set with prg flags, or am I missing something?
Or was the blitter question brought up earlier and I missed it?

You can use TOS4 with NVDI (see screenshots on the previous page), but it has to use the onboard ROM instead of my flash.

I'll probably have a go at getting EmuTOS to allow blitter down the road (ie. hardware blitting is only used when source and destination are in ST-RAM) -- but it's not a priority ATM.

EMUTOS has come far, but it's not TOS 4.04 IMHO. It's driving far over to the emulator side of things. Was following the dev list, but it got too much into support for features in very low TOS versions that have been traditionally patched to fix. A lot for the sake of just being open source.....

Yep. But it's a silver bullet for me at the moment. I have a custom, targeted version for my board. I don't need to worry about patching TOS4 yet.

...and patching TOS4 is the answer. cf. CT60.

To add insult to injury, MiNT runs much nicer than TOS does now, the only limiting factor using it on a stock Falcon. Your board changes that game

MiNT is lovely with ETOS+NVDI+128MB AltRAM. It's even usable in 256 colour mode. I should make a video.

BW

[joska]

It's driving far over to the emulator side of things.

On the contrary, there is very little emulator-specific stuff in EmuTOS. I'm using it on real hardware only and it's a really, really great OS. It supports virtually all Falcon hardware except 16 bit colour.

[Rustynutt]

It's driving far over to the emulator side of things.

On the contrary, there is very little emulator-specific stuff in EmuTOS. I'm using it on real hardware only and it's a really, really great OS. It supports virtually all Falcon hardware except 16 bit colour.

And 040 mmu support?

It is a great project and didn't intend to take anything away from the work everyone is putting into it. It is the future.

It seems they are getting cramped for space with a 512k limit. Kind of read into that some of the added features such as recognizing hardware that is traditionally done with programs such as HDDriver, and support for some of the "obscure" 030 projects, not that the AB is much different in that respect, just more forgotten.

[joska]

And 040 mmu support?

Yes. But for Aranym, it needs some tweaking to work with the AB. In it's current state it crashes as soon as you enable TT-RAM on the AB. It will also need some cache tweaking.

It seems they are getting cramped for space with a 512k limit. Kind of read into that some of the added features such as recognizing hardware that is traditionally done with programs such as HDDriver, and support for some of the "obscure" 030 projects, not that the AB is much different in that respect, just more forgotten.

The lack of space is caused by EmuTOS 512K having a lot of different languages compiled in, unlike TOS which only has 4 (IIRC). There has been some changes done here lately which leaves a ton of space left in the 512Kb version.

[Badwolf]

The lack of space is caused by EmuTOS 512K having a lot of different languages compiled in, unlike TOS which only has 4 (IIRC). There has been some changes done here lately which leaves a ton of space left in the 512Kb version.

I agree as a big fan of EmuTOS.

It does have some emulator support with NatFeats and an extended OS Header, but that's not at that cost of other features in the ROM. The version of EmuTOS I'm using has 250k of 512k free!

But there's a distinct speed and comfort advantage to running TOS4 natively as the EmuTOS team aren't trying to be better than TOS. In fact they've a policy of not adding features they don't consider appropriate to an OS. Fortunately, IMO, a hard disc driver isn't one of those (but I shan't praise it too loudly or they might take it away again ).

Anyway, at present I can customise EmuTOS and I can't TOS4, so that's why I'm using EmuTOS.

BW

[czietz]

But there's a distinct speed and comfort advantage to running TOS4 natively as the EmuTOS team aren't trying to be better than TOS.

I strongly contest that statement. EmuTOS is very much better than Atari TOS (not just trying but already achieving that) in many regards: hard disk driver (you mention that), much superior FAT16 filesystem support compared to TOS, native support for a lot of third-party hardware, support for many more languages than TOS, and more.

In fact they've a policy of not adding features they don't consider appropriate to an OS.

For sure, such a policy must always exist, if you don't want to end up with feature-creep and a messy, impossible to maintain codebase. Apart from that, ROM size also limits what can be done.

[Badwolf]

Anyway, EmuTOS' completely clear-cut and not-at-all Schroedinger-like feature policy aside, I like EmuTOS as I can customise it.

I can't do with that TOS4 yet, so I'm specifically targeting my board for EmuTOS ATM.

BW.

[joska]

TOS 4 sources are "out there" so customisation is not really a problem. *Distributing* a modified TOS OTOH...