exxos's Atari, Amiga & retro forum

Wow... :o This is just amazing. I've been waiting for a Falcon re-make but this is even cooler. Incredibly impressive work :)

Looks incredible @agranlund!

I'd be on a ferry over to see it in person if I had an 060 to go in it...and maybe an Atari cartridge port connector (just in case any of the MIDI sequencers works with an 060 processor)...

:thumbup:

Cyprian wrote: 11 Apr 2024 20:52 awesome
@agranlund Can you benchmark it with GemBench, Kronos or NemBench?

ok, I see some tests:

Cyprian wrote: 11 Apr 2024 22:12

Cyprian wrote: 11 Apr 2024 20:52 awesome
@agranlund Can you benchmark it with GemBench, Kronos or NemBench?

ok, I see some tests:

Hey Cyprian! Yep there's that one with some benchmarks.
It's all a bit of a moving target and I'm going for just making things work and optimise later. Hence, it doesn't do burst read/writes yet and no Copyback cache etc. I have some 10ns rams here and it'll be interesting to see what 0-waitstate burst would do to it but all in due time :)
Still, the coremark is not too shabby.

In the interest of managing expectations though, this computer is severely bottlenecked in the graphics department by design.
I'm sure it's not everyones cup of tea, but as a toy for myself I am more than happy with that.

ISA was chosen for these reasons:
1) I am fairly certain I can get that working on the hw side.
2) I will be able to easily make my own types of expansion cards + drivers
3) Homemade cards in the PC retro community are for ISA

I've seen videos from the PC community pushing some ISA gfxcards way over spec but even so, it's far from what a PCI card can do.


Unfortunately I haven't been unable to run Nembench and Gembench yet :/

Nembench crashes right after displaying the first message.
My uneducated guess is maybe it's going boom on FPU access - I have not yet implemented soft-FPU for LC variants.

It has a different problem with Gembench.
The GEM window test is the only one that actually runs. All others will start but immediately get stuck and never finish.
Ie; the blitting test draws the box at its first location but it never moves. I can see the CPU is executing code from TT-RAM but I'm not sure what.
@exxos , would you know what Gembench might be waiting for? Is it depending on the HBlank interrupt, or using TimerB to count hbls?

My bios has a background monitor/debugger which I can break into but it's a work in progress like everything else and doesn't have disassembly or trace functionality yet. Getting that in should help ironing out these types of issues.

agranlund wrote: 12 Apr 2024 09:42 The GEM window test is the only one that actually runs. All others will start but immediately get stuck and never finish.
Ie; the blitting test draws the box at its first location but it never moves. I can see the CPU is executing code from TT-RAM but I'm not sure what.
@exxos , would you know what Gembench might be waiting for?

GEM window test is the only test which doesn't disable the keyboard interrupts. It would always screw up the tests no idea why.

I guess if you fake the acia registers it would probably be enough. Just issue DTACK on it...

exxos wrote: 12 Apr 2024 09:50

agranlund wrote: 12 Apr 2024 09:42 The GEM window test is the only one that actually runs. All others will start but immediately get stuck and never finish.
Ie; the blitting test draws the box at its first location but it never moves. I can see the CPU is executing code from TT-RAM but I'm not sure what.
@exxos , would you know what Gembench might be waiting for?

GEM window test is the only test which doesn't disable the keyboard interrupts. It would always screw up the tests no idea why.

I guess if you fake the acia registers it would probably be enough. Just issue DTACK on it...

Awesome, thank you!
The code is indeed in a loop reading from the ACIA control register and waiting for a certain result.
I should be able to emulate the ACIA regs.

That's a great creation, congratulations :)

Faking those ACIA registers made Gembench happy :)

The Gembench I could find in my mess only had the stfm as default reference so I think I'll have to copy the stuff from my ST which has the complete package.

EmuTOS built-in driver:


EmuTOS built-in driver + NVDI:


NVDIVGA driver 8bpp:
(sorry for photo, the screenshot feature was grayed out in this mode)


EmuTOS's built-in driver is mono only, hence those mono tests.
I still haven't tested the Nova driver.

It's all a bit work in progress but I assume the display numbers will stay somewhat in the ballpark -- that ET4000AX card is signalling for waitstates to keep things quite slow, and it shows on those 8bpp results.
I have some hopes that the Mach32 can be driven harder, the same chip was used on PCI cards after all.

I'm expecting the RAM speeds to go up but it can stay like it is for now until I revisit that part later.
All RAM is currently in Writethrough mode, burst mode is not implemented yet and there are some waitstates involved which the faster RAMs wouldn't need.

:bravo: :2k2:

I'm not sure how accurate the scores are when you start to get below 1 second test times. There's only the 200hz timer tick per second to count against.

Be interesting to see the first test with caches turned off (no NVDI) .

agranlund wrote: 12 Apr 2024 15:02 EmuTOS built-in driver + NVDI:
<snip screenshot showing 30x averages or so>

It's alright, I suppose...

:lol:

BW