Alt-RAM logic brain fart

[Badwolf]

That was it!

It needs a bit of tweaking, and it's only 1MB in the end, but as proof-of-concept goes, I'm happy with it.

Oh, and a Frontier shot is required, I suppose

BW

IMG_3832.jpeg (72.88 KiB) Viewed 4567 times

IMG_3834.jpeg (127.37 KiB) Viewed 4567 times

IMG_3833.jpeg (75.79 KiB) Viewed 4567 times

[JezC]

Nice! It'll be interesting to see any further developments too...

[Badwolf]

Nice! It'll be interesting to see any further developments too...

Thanks! Next step is to tidy up the logic and then try to figure out why TOS4 and Gembench 6 crash.

I think it's related to the 030 MMU -- I have had to disable it in EmuTOS. Perhaps I've got something incorrectly wired up on the chip itself... certainly wouldn't be out of character!

BW

[Badwolf]

More progress!

Did you implement all the cases for the combinations of of SIZ1, SIZ0, and A0 as described by 68030UM? In particular the combinations where you also have to provide the previous/next byte in memory for byte-sized accesses?

This was the key to TOS 4 not working, thanks @czietz. Disabling MMU in EmuTOS must have also disabled the cache. I had only accounted for the write cycles in my logic.

Happy to report that I can now boot TOS 4 and run Gembench 6. Here are the before and afters:

before.png (513.79 KiB) Viewed 4537 times

after_20200927.png (564 KiB) Viewed 4537 times

The most obvious issue is that standard memory access is ~10% slower than stock. That's a problem since that's required for all video writes.

I switch back to Falcon clock when /AS drives low, but do so through a twin flip-flop arrangement that's designed to allow dissimilar clocks to avoid glitching (if you switch mid-cycle you could end up with an effective clock rate spiking well over 50MHz). This causes two problems because there's often one really slow clock cycle entering a bus cycle whilst we hold at a fast clock falling edge and wait for a falcon clock falling edge. The first is that we see this hit in memory access speed and the second is that we can't run stably in 8MHz mode, as this slow clock cycle can fall below the 030's minimum frequency. Firmware work is needed to mitigate the first. The second I've got around by launching in 'slow' mode and only engaging the accelerator when a particular memory address is written to -- ie. after the switch to 16MHz.

Anyway, here's what this particular development revision (dev2b) looks like. A few bodges to incorporate into the next version. My impressive status panel is also visible: red is accelerator enabled. White is 48/16MHz. Blue is an altram access.

clean_board.png (806.57 KiB) Viewed 4537 times

Finally, as a bit of fun. Here's another Frontier demo. I think the real bottleneck here is the memory writes for video, but all three LEDs are glowing brightly during the accelerated half of this:

I'm very pleased with progress recently. Thanks for the help, everyone & to Stephen Leary for kicking me into action with his TerribleFire series and getting me started with the CPLD code. This will all eventually end up open source too.

Next steps are more firmware work, some software work (I need to resolve the TOS4 blitter + AltRAM issue -- BlitFix doesn't seem work on TOS4), and then I need to start investigating DRAM as my AltRAM is small and is only 16 bit. Preferably something 5V tolerant and not too demanding on pin count!

BW.

[exxos]

Great work! I guess you could copy TOS4 into fast-ram and get full 32bit access to it aswell ?

Edit : ah just saw 16 bit so never mind Still a great project. Was something i wanted to do on the falcon but time is never on my side.

[agranlund]

Great stuff, this is super impressive! (I love the status panel btw )

BlitFix doesn't seem work on TOS4

Yeah, it was easy to accomplish for TOS 2.06 since both the HW and SW blit routines exists in TOS already.
It was just a matter of hijacking the calls and make it jump to the SW routine when alt-ram is involved.

I could be wrong but I think the SW routines were removed from TOS4 so they would have to be reimplemented and supplied by Blitfix in that case..
(not something I am eager to do, but the source is on Github if someone else wants to )

I'm pretty sure NVDI on the Falcon will make sure the Blitter is not being touched though?

[Badwolf]

Great work! I guess you could copy TOS4 into fast-ram and get full 32bit access to it aswell ?

Edit : ah just saw 16 bit so never mind Still a great project. Was something i wanted to do on the falcon but time is never on my side.

Thanks!

I suspect that ROM access figure of 250% is down to Anders’ maprom.prg, which does just that. Of course only 16 bit ATM and cheating really as still has a rogue blitter on in the background making any real programs unstable, but huge strides from where I was only a week ago, even.

BW.

[Badwolf]

Great stuff, this is super impressive! (I love the status panel btw )

The status panel’s my best work!

BlitFix doesn't seem work on TOS4

Yeah, it was easy to accomplish for TOS 2.06 since both the HW and SW blit routines exists in TOS already.
It was just a matter of hijacking the calls and make it jump to the SW routine when alt-ram is involved.

I could be wrong but I think the SW routines were removed from TOS4 so they would have to be reimplemented and supplied by Blitfix in that case..
(not something I am eager to do, but the source is on Github if someone else wants to )

That makes sense. I did try to read the source last night, but my 68k assembly and knowledge of Falcon hardware control is not quite as good as my status panel engineering

I'm pretty sure NVDI on the Falcon will make sure the Blitter is not being touched though?

Great idea! I’ve tried emutos + NVDI, but that does sound like an easy win with TOS.

Thanks for the reply. I was intending to tap you up at some point to discuss the TFtools. One step at a time!

Cheers,

BW.

Etos+nvdi:

9BC3FC84-62D0-4E57-BD42-A574AA5ADD49.jpeg (797.37 KiB) Viewed 4519 times

[exxos]

Yeah, having ultimately ROM in 32 bit fast RAM would help the poor crippled falcon along. Of course 32bit RAM will speed things up no end.. Let alone with a 50mhz 030.

Though really, you should be able to run the CPU at full speed all the time anyway. Mostly you just have to resync DTACK ... Wait like 2 8mhz clocks then let the cpu see dtack kinda thing. Similar with bus grant stuff, have to emulate what the 8mhz CPU would basically do. You could see how terriblefire does it on his accelerators anyway. Now it could be possible to port that to the falcon...

[agranlund]

Maprom remaps a small part of low ST-RAM to Alt-ram as well, avoiding some page(s) that contain stuff TOS absolutely must have in ST-RAM.
I can't say for sure if that thing is 100% safe on all TOS's or if this could cause any stability issues for you.

Looking at it now I see that it does 32Kb for TOS2.06 and 4Kb for all others (and my comment says 0Kb for EmuTOS, which is not what the code is doing )

If you have Devpac3 you could try disabling that part just to be on the safe side. Or I can rebuild it for you during the week, I want to double check if this could be the reason for the floppy issues anyway.

Near the top of maprom.s:

OPT_RELO_RAM SET 1
to
OPT_RELO_RAM SET 0