Using the Falcon's expansion connector

[dhedberg]

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

The complete sources?

[shoggoth]

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

You don't need the sources to modify the VDI functionality in question; there's a jump table in the LineA table for this purpose. Patch Vsetsscreen() so that you execute some minor things immediately when returning from XBIOS, and that's it. No need to patch the actual VDI.

[Badwolf]

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

You don't need the sources to modify the VDI functionality in question; there's a jump table in the LineA table for this purpose. Patch Vsetsscreen() so that you execute some minor things immediately when returning from XBIOS, and that's it. No need to patch the actual VDI.

The nice thing about open source is I only need to get the hardware stable and published then appeal for help to someone to whom the above isn't Greek!

To be honest far higher up the priority list will be DSP support. Presently it doesn't work at all. To the point that I've stripped it out of my EmuTOS build for the time being.

I see that the DSP talks to the CPU on an 8 bit bus, so DSACK0 is asserted instead of DSACK1. That's fine, I can synthesise that. But it still doesn't work. I was reading around the old CT2 websites about DSP_IRQ patches and suchlike, so it's not an unknown problem, but I can't figure out what's *meant* to happen. I'm not seeing the spurious interrupt messages that were apparently the problem at the time and I can't find any clear documentation on how the CPU and DSP are *meant* to talk to each other.

I put this investigation off to concentrate on getting the SDRAM stable. I'm not 100% happy with that and -- depending on what feedback I get from @alexh -- I may have to return to that anyway. When that's out of the way I'll need to make a decision on whether Rev4 precedes or comes after DSP research.

I'm building a second copy of the rev3 board at the moment to see what the minimum number of bodge wires really is and whether I can replicate this firmware's behaviour with a second board so, to be honest, DSP and TOS4 support are probably further away than this discussion would seem to imply.

BW

[Rustynutt]

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

Always read that file is an incomplete source. But most of what I know is only historical, with some mythology thrown in.

I've never fully understood why once TOS is located into RAM, a tool such as BSS Debug can't be used to copy a patched TOS in memory area and used as a suitable flash image.

Other than only a couple people on the planet actually patch TOS in RAM, as opposed to applying TSR patches.
I've used it to perform simple mods to applications, and save them back out as binaries. Oh, the pain of copyright infringement....wait, all abanded now

But that question likely shows my ignorance.

Something I've not ever seen, at least in English forums, is, has the big hairy monster question ever been put to "its owners"? This last group, at least in the beginning really had no interest in "this old stuff". Who knows now though, maybe they want TOS to control water fountains at their motels.

It's odd, then not, this test board sees ROM at the defined address, then during startup, the COMBEL looks to the onboard ROM.
Ignorantly think how does this work, say, using ROMSPEED after boot.

So this card is reading onboard ROM during startup, but early on in the sequence when the COMBEL is awoke, it reads TOS on the MB.
Gotta be the bus GALS in that mix somewhere.

Ok, I'll be quiet.

[Badwolf]

It's odd, then not, this test board sees ROM at the defined address, then during startup, the COMBEL looks to the onboard ROM.
Ignorantly think how does this work, say, using ROMSPEED after boot.

So this card is reading onboard ROM during startup, but early on in the sequence when the COMBEL is awoke, it reads TOS on the MB.
Gotta be the bus GALS in that mix somewhere.

Sorry, was this a question to me? I'm afraid I don't understand it, if so.

BW.

[Rustynutt]

It's odd, then not, this test board sees ROM at the defined address, then during startup, the COMBEL looks to the onboard ROM.
Ignorantly think how does this work, say, using ROMSPEED after boot.

So this card is reading onboard ROM during startup, but early on in the sequence when the COMBEL is awoke, it reads TOS on the MB.
Gotta be the bus GALS in that mix somewhere.

Sorry, was this a question to me? I'm afraid I don't understand it, if so.

BW.

It seems you are still researching this as to why it occurs.

[Badwolf]

It's odd, then not, this test board sees ROM at the defined address, then during startup, the COMBEL looks to the onboard ROM.
Ignorantly think how does this work, say, using ROMSPEED after boot.

So this card is reading onboard ROM during startup, but early on in the sequence when the COMBEL is awoke, it reads TOS on the MB.
Gotta be the bus GALS in that mix somewhere.

Sorry, was this a question to me? I'm afraid I don't understand it, if so.

BW.

It seems you are still researching this as to why it occurs.

Why what occurs?

I'm not researching anything with the ROMs.

I was (and will continue to be) researching the limits of my SDRAM controller. Now I'm bringing up a second board. Later I'll be researching the DSP.

BW

[sigmate]

Just a word to say thank you and all the best for your work. It’s fascinating.

[Rustynutt]

Sorry, was this a question to me? I'm afraid I don't understand it, if so.

BW.

It seems you are still researching this as to why it occurs.

Why what occurs?

I'm not researching anything with the ROMs.

I was (and will continue to be) researching the limits of my SDRAM controller. Now I'm bringing up a second board. Later I'll be researching the DSP.

BW

Sorry, I'm quoting your statement about the CPU can read your onboard ROM at your specified address, but when the COMBEL access ROM, it reads from the motherboard ROM.

Ring a bell?

That's where I started in with the GALS, and that is just talking out loud.

[viking272]

Just a word to say thank you and all the best for your work. It’s fascinating.

Indeed, good work BW.

[Badwolf]

Sorry, I'm quoting your statement about the CPU can read your onboard ROM at your specified address, but when the COMBEL access ROM, it reads from the motherboard ROM.

Ring a bell?

That's where I started in with the GALS, and that is just talking out loud.

Oh right, sorry. That wasn't a question, it was a statement.

When my CPU reads from 00Exxxxx *my* CPLD enables the onboard flash to serve the request. The motherboard never knows about it. If the blitter tries to access 00Exxxxx, however, COMBEL enables the motherboard ROM to service the request as normal.

This is as expected, but it means you can't blit from an external ROM any more than you can blit from an external RAM (ie AltRAM).

Since TOS4 blits from ROM at the very very outset (the Atari logo is blitted onto the screen) either TOS has to be patched (as in the ROM image -- it's too early to load any programs), or the onboard ROM used.

When I'm testing in TOS4 mode, I simply disable my flash ROM.

BW

[Badwolf]

Just a word to say thank you and all the best for your work. It’s fascinating.

Indeed, good work BW.

Thank you, guys. Appreciated.

Especially as I managed to destroy £40 worth of CPLD chips in an hour yesterday. Sometimes you just have one of those days!

BW

[MegaSTEarian]

How's things in the expansion accelerator front?

[Badwolf]

I was *this* (small amount) close to publishing benchmarks for a working second Rev3 card when the damned brand-new especially-ordered CPLD blew up.

Another £20 down the gurgler.

Attempts to fit my current design into the cheaper chip didn't work, so I ordered the pricer one and it had just gone through some trials (I'd fitted less SDRAM to prove that would work as well). I'd made some arithmetic errors which had stalled me for a couple of days but I'd just got there and was happily running Doom on my 40MHz test CPU.

Removed the board to change over to the 50MHz chip for benchmarking. When I put it back in the LEDs flickered half brightness and black screen. Removed it and refitted it: no signs of life.

Tested a few connections. Dead short to ground on many pins, including the whole 3V3 rail. The chip had gone bang.

Put back in my other board and it failed to initialise until I wiggled it around a bit. I think, unfortunately, my Falcon expansion header has some intermittent contact problems. Probably from overuse. I suspect the CPLD received 5V signals from the motherboard without it's 3V3 power rail established because of those bad connections. It's the third chip to fail this way, so something's wrong.

It's extremely frustrating and starting to get extremely expensive. I think I might add an extra step in the development process and trial two different CPLDs on the next board. Two lower-spec'd (ie. cheaper) chips. More soldering but if any single one goes bang, it's less of an overhead.

Anyway, when my next replacement arrives I'll try again. If I can prove this second board is stable at 50MHz, I'll move onto the next phase.

I can report the 128MB version is *just about* capable of running OpenTTD, though (runs about about 1/3 speed, maybe):




And, of course, having memory does let you do things you *really shouldn't*:



Of course neither are remotely usable when run simultaneously, and you can see the problem with a 256 colour palette but try doing it on stock!

BW

[MegaSTEarian]

Looks good. What is the final memory configuration your targeting at? 256 or 512MB?

And I guess 50MHz will be the milestone, right? I believe 68030 cannot go any higher and still be stable, can it?

It is amazing what the Falcon can do with just a little push. I have a Falcon running at 32MHz and I bet it is faster than my TT or at least feels faster.

[czietz]

It is amazing what the Falcon can do with just a little push. I have a Falcon running at 32MHz and I bet it is faster than my TT or at least feels faster.

It would be interesting to see your Falcon's CoreMark results (and of course those of @Badwolf's accelerator). The 32-MHz-Falcon result that was submitted there is actually a fair bit slower than a TT:
https://github.com/czietz/coremark/wiki/Results
https://github.com/czietz/coremark/rele ... atari_port

[sety]

It's extremely frustrating and starting to get extremely expensive. I think I might add an extra step in the development process and trial two different CPLDs on the next board. Two lower-spec'd (ie. cheaper) chips. More soldering but if any single one goes bang, it's less of an overhead.

I'm more than happy to help blow up some CPLDs at my own expense, should you wish to release some early Gerbers or send us one of your surplus bare boards. No reason to go it alone while testing.

[Badwolf]

Looks good. What is the final memory configuration your targeting at? 256 or 512MB?

The sweet spot is probably 64MB. Same as the TF536. The range will probably be 32 to 128. Up to the builder as it affects the cost of the build considerably. Not sure if I'll have it set with jumpers or just have different firmware builds.

And I guess 50MHz will be the milestone, right? I believe 68030 cannot go any higher and still be stable, can it?

It should work between 40 and 50MHz. It'll be up to the builder to pair suitable CPUs and clocks.

There is an upper limit where the memory would need different timings, but the CPU is likely to flake out first. Haven't had anything running over about 55MHz.

It is amazing what the Falcon can do with just a little push. I have a Falcon running at 32MHz and I bet it is faster than my TT or at least feels faster.

The Falcon's always going to be crippled by the 16-bit, 16MHz ST RAM. TT of similar clock frequency is always going to be quicker, I'm afraid. But we're narrowing the gap.

BW

[Badwolf]

It would be interesting to see your Falcon's CoreMark results (and of course those of @Badwolf's accelerator). The 32-MHz-Falcon result that was submitted there is actually a fair bit slower than a TT:

I have actually run it (23.59@50MHz), but haven't submitted results as still in R&D and therefore may change.

Unsurprisingly (given it's almost exactly the same technology) it's virtually the same as the TF536.

BW

[Badwolf]

It's extremely frustrating and starting to get extremely expensive. I think I might add an extra step in the development process and trial two different CPLDs on the next board. Two lower-spec'd (ie. cheaper) chips. More soldering but if any single one goes bang, it's less of an overhead.

I'm more than happy to help blow up some CPLDs at my own expense, should you wish to release some early Gerbers or send us one of your surplus bare boards. No reason to go it alone while testing.

Great to hear, sety!

The problem I have at the moment is the only working board has a lot of bodge wires as I've re-routed pins. That means the firmware wouldn't work on another build. One of the reason I was building up the second board was to try to build a firmware would work without all the corrections.

I'm very tempted to publish once that's proven and I can have a 'baseline' firmware.

However there is a small issue with that. This board, for the purposes of development, was not built to proper dimensions. It's about 1.5mm too wide to allow the PSU to fit.

For that reason I'm equally as tempted to hold off publishing until Rev4 where I can fix the one obligatory bodge wire and meet the form factor goal.

I think let me firm up the configuration for the firmware when I can complete the build of board 2 and then I'll take stock.

Cheers,

BW.

[Rustynutt]

Put back in my other board and it failed to initialise until I wiggled it around a bit. I think, unfortunately, my Falcon expansion header has some intermittent contact problems. Probably from overuse. I suspect the CPLD received 5V signals from the motherboard without it's 3V3 power rail established because of those bad connections. It's the third chip to fail this way, so something's wrong.

BW

As you (and likely everyone that has cursed the expansion pins) have found out, that part of the Falcon wasn't considered to be "easy" access by users.

I use these test extensions almost exclusively up to the point to actually putting the top cover back on

Also have a set that lifts expansion cards about 12mm, with pins exiting at 90 degrees on the sides, and able to connect flat ribbon for access to the Falcon expansion without prodding around top of the expansion card itself.
But I have shakey hands

I'm sure you do, will throw this out there, when taking 5Vcc power from the expansion pin, the IC converting to 3.3Vcc is well regulated? Power from the expansion pin isn't, other than what the powersupply does and traveling through the big cap. Also, just for the sake of doing so, and saving discussion, you are "well grounded" outside of using the ground provided on the expansion connector?

Just an example, not fact, have a Falcon now on the bench. Very inconsistent booting and stability issues. Just the board, and powersupply. After clipping leads from the PS bracket to cartridge port shield, bracket to other ground rail points zen was achieved

Looks like your board is in the lower case and powersupply secured though.

[Badwolf]

I use these test extensions almost exclusively up to the point to actually putting the top cover back on

That is advice I wish I'd had six months ago! Very good idea.

Also, just for the sake of doing so, and saving discussion, you are "well grounded" outside of using the ground provided on the expansion connector?

Just an example, not fact, have a Falcon now on the bench. Very inconsistent booting and stability issues. Just the board, and powersupply. After clipping leads from the PS bracket to cartridge port shield, bracket to other ground rail points zen was achieved

This is an excellent suggestion and one I hadn't considered. Having a secondary supply and ground line during development could very well save some some misfortune.

I do make sure I use all the ground and 5V lines so as not to put my eggs in too few baskets, but I've seen how flakey the expansion connector is so think I'll definitely add some external lines going forwards.

Cheers for the tips,

BW.

[Badwolf]

Quick update, guys. I haven't done any further development this week whilst waiting for some replacement parts.

If I can get this 32MB version running reliably, I'm I'm thinking of doing an extra revision with two, cheaper, CPLDs rather than one big expensive part.

It'll delay the final version by a spin, but the cost of these is a big design goal for me and having a single part that, if you blow it up, is a quarter the BOM cost is too risky for my tastes.

I've been doing a bit of software work in the meantime which I hope will have a direct connection to the booster, so all's good.

BW

[MegaSTEarian]

It is amazing what the Falcon can do with just a little push. I have a Falcon running at 32MHz and I bet it is faster than my TT or at least feels faster.

It would be interesting to see your Falcon's CoreMark results (and of course those of @Badwolf's accelerator). The 32-MHz-Falcon result that was submitted there is actually a fair bit slower than a TT:
https://github.com/czietz/coremark/wiki/Results
https://github.com/czietz/coremark/rele ... atari_port

I have packed it and left it rest for a while as I am working on a stock box now, trying to rebuild it and attempt a MiNT/EasyMiNT installation. Time is a problem though. So the benchmarks will take some more time

[MegaSTEarian]

It is amazing what the Falcon can do with just a little push. I have a Falcon running at 32MHz and I bet it is faster than my TT or at least feels faster.

The Falcon's always going to be crippled by the 16-bit, 16MHz ST RAM. TT of similar clock frequency is always going to be quicker, I'm afraid. But we're narrowing the gap.

BW

Yeah, but it feels faster and more robust. TT OTOH is crippled because it doesn't have the Falcon's bells and whistles