Alt-RAM logic brain fart

General discussions or ideas about hardware.
Badwolf
Posts: 56
Joined: Tue Nov 19, 2019 12:09 pm

Re: Alt-RAM logic brain fart

Post by Badwolf » Fri Sep 25, 2020 10:33 pm

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

Oh, and a Frontier shot is required, I suppose ;)

BW

IMG_3832.jpeg
IMG_3832.jpeg (72.88 KiB) Viewed 259 times
IMG_3834.jpeg
IMG_3834.jpeg (127.37 KiB) Viewed 259 times
IMG_3833.jpeg
IMG_3833.jpeg (75.79 KiB) Viewed 259 times

User avatar
JezC
Trusted Guru
Trusted Guru
Posts: 791
Joined: Mon Aug 28, 2017 11:44 pm

Re: Alt-RAM logic brain fart

Post by JezC » Fri Sep 25, 2020 10:58 pm

:goodpost: :coolpics:

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

Badwolf
Posts: 56
Joined: Tue Nov 19, 2019 12:09 pm

Re: Alt-RAM logic brain fart

Post by Badwolf » Fri Sep 25, 2020 11:42 pm

JezC wrote:
Fri Sep 25, 2020 10:58 pm
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
Posts: 56
Joined: Tue Nov 19, 2019 12:09 pm

Re: Alt-RAM logic brain fart

Post by Badwolf » Sun Sep 27, 2020 11:30 pm

More progress!
czietz wrote:
Thu Sep 24, 2020 7:44 pm
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
before.png (513.79 KiB) Viewed 229 times
after_20200927.png
after_20200927.png (564 KiB) Viewed 229 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
clean_board.png (806.57 KiB) Viewed 229 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.

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

Re: Alt-RAM logic brain fart

Post by exxos » Sun Sep 27, 2020 11:32 pm

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 :lol: Still a great project. Was something i wanted to do on the falcon but time is never on my side.
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: 332
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Alt-RAM logic brain fart

Post by agranlund » Sun Sep 27, 2020 11:59 pm

Great stuff, this is super impressive! (I love the status panel btw :D)
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
Posts: 56
Joined: Tue Nov 19, 2019 12:09 pm

Re: Alt-RAM logic brain fart

Post by Badwolf » Mon Sep 28, 2020 12:58 am

exxos wrote:
Sun Sep 27, 2020 11:32 pm
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 :lol: 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
Posts: 56
Joined: Tue Nov 19, 2019 12:09 pm

Re: Alt-RAM logic brain fart

Post by Badwolf » Mon Sep 28, 2020 1:07 am

agranlund wrote:
Sun Sep 27, 2020 11:59 pm
Great stuff, this is super impressive! (I love the status panel btw :D)
The status panel’s my best work! :D
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
9BC3FC84-62D0-4E57-BD42-A574AA5ADD49.jpeg (797.37 KiB) Viewed 211 times

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

Re: Alt-RAM logic brain fart

Post by exxos » Mon Sep 28, 2020 1:09 am

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...
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: 332
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Alt-RAM logic brain fart

Post by agranlund » Mon Sep 28, 2020 2:17 am

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 :lol:)

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

Post Reply

Return to “HARDWARE DISCUSSIONS”