No problem. It's just stolen code from the examples with Bare Metal Programming really. Could be a simple problem, just haven't got round to debugging it as its hardware only.

Tell me about it. Also OutRun draws back to front (i.e. furthest away stuff first) as you'd kind of expect the original programmers to do, given they had some amazing sprite hardware at their disposal!

I assume you have taken over vblank interrupt from system? Otherwise it will reset ciab tod every frame. Also TOD latch doesn't work if ALARM bit is set. There is also TOD alarm bug, but don't think it will affect this case (though I could be wrong).

For figuring out where time is spent use some kind of timer around interesting sections of code. If you have clearly defined high level "sections" e.g. "game logic", "c2p", "sprites" etc. it should be fairly easy to time the easy of the and report numbers on screen (or accumulate time for each time e.g. specific functions are called, and report once per frame). That should help you narrow down where difference vs UAE is (probably something CPU heavy as chipset timing is usually accurate enough).

If you have system available and KS2+ timer.device is fine and straightforward, if system is off CIAB TOD timer is good enough for rough estimates, otherwise just use a normal CIA timer (set reload value to $ffff, START+LOAD <run code> stop timer and read elapsed ticks).

If you mean, do I have my own VBlank routine running, then yes I do. It doesn't do much at the moment beyond updating the palette caching I mentioned (i.e. it updates colour registers based on what the main loop code previously queued).

System is off, so I'll use the CIA timer. It looks pretty straightforward.

The code is very good and avoids the not satisfactory blocking delay loop which steals CPU cycles...

unless interrupt level 6 is not active or overwritten by something else like music player. It's interrupt level 6 which performs the handshake with proper timing. Check if the level 6 interrupt really calls CIAB_Handler

They had hardware sprite & zooming. Not the same league... Even the guys at Atari complained of the lack of this hardware when they designed Road Wars

I dont think that using asr.w and asl.w is very good code. only lsr.w lsl.w is good for me for this case. Same for using movem.l d0,-(sp). If no special tricks for CCR handling, this is not good code. Most assemblers with auto optimisations as default will be change this to move.l d0,-(sp). Perhaps at end movem.l will be replaced with move.l too. I dont know if this movem.l is necessary for handling ACK.

Either way, the expected keyboard behaviour, which works in UAE, as an example:
1/ Hold down left or right cursor. Scroll world left and right until depressed. It's responsive and 100% reliable.

On hardware I get:
1/ Hold down left or right cursor. World scrolls for a bit then stops. Then keypresses are intermittent or most likely not registered at all.

Is it possible that I'm punishing the CPU so much on hardware that something else is grabbing priority from the interrupt handler?! Is that even possible.

I guess some debug code on hardware will once again help. The last thing I expected, out of all the things to not work on hardware, was my borrowed keyboard routine!!

Recent WinUAE versions log warning message if keyboard handshake is too short. UAE won't care if pulse is too short or too long, too many programs have CPU delay loops and different keyboard models have different handshake pulse requirements which forces UAE to accept everything.

Usual easy check: flash background color in both interrupts routines, do the flashes appear in correct order and in same frame?

btw, there is no need to write anything to CIASDR (Why some examples have it? It has never been needed), setting serial port outmode bit is enough (and is what KS ROM also does)

btw2, clear bit #7 of CIABCRB, at least when exiting your code to not confuse KS ROM routines too much.

btw3, CIAs are slow to access, reading and writing all TOD registers wastes time, it probably is more optiomal to keep static ALARM value and only reset the TOD every time you need to "start" the timer.

interrupt 6 can't be delayed by other ones as it has highest priority. But if you're using move #$2700,SR each time you enter in a VBLANK that could delay (but not mask) cia 6. If you clear interrupt request with 7FFF and not $20 or $10 (relevant interrupt) then you could clear another interrupt request (but CIAs would keep interrupting so it doesn't apply here)

Color flashes are a good method, Toni is right (as always)

Thanks for your responses. For the keyboard handling, in the end I studied the WHDLoad code and wrote a version based off that.

It's far simpler than what I had before, and works perfectly on hardware.

I didn't get to the bottom of where the previous implementation was failing on hardware. I did try modifying the timing values, but to no avail.

Anyway, here's the working code based off of WHDLoad's Keyboard.s
Other than that I've been doing some general house-keeping. Removing the massive INCBINs for the sprites and other graphics - dynamically allocating memory and loading them from disk instead. The binary is now a manageable size.

Now that I have a working keyboard on hardware, I can start timing various blocks of code.

In a somewhat unexciting moment, the stats are in. See attachment.

Left Monitor: Real Amiga
Right Monitor: WinUAE

Big number bad. Small number good.

As you can see my road routine kicks ass because it's highly optimized. The sprite routine provides enough time to make a cuppa whilst it renders. The C2P is slower than I expected, although I dunno what I was expecting.

Inevitably, the sprite routine is mega slow because it does so much heavy lifting. And because I haven't started the second round of optimizations yet.

The good thing is that I can now feel good, slowly shaving numbers of these values as I improve the routines. I can also tweak UAE settings to more closely match performance on hardware potentially.

Other than that, I fixed the sprite layout bug that was annoyingly me tremendously. And got a few later stages of the game rendering for fun.

There won't be anything particularly sexy to report for a while other than numbers decreasing.

> Other than that, I fixed the sprite layout bug that was annoyingly me tremendously.

You can't say that and not tell us what it was!?!

I look forward to seeing a series of decreasing numbers.

As expected, a totally ridiculous bug of my own making. I wrote a routine that assumed an address register was previously set and it wasn't. Once found, very obvious. But there were approximately 100 obvious places to look before I found that one! Also the routine kind of half worked even though it was writing to the wrong area of memory.

To get as close to real Amiga timings you need to tick both Cycle Exact boxes in the chipset tab on winuae. Without that winuae in AGA mode will fly compared to real Amiga, regardless of the accelerator.

I'm using those settings already on WinUAE. I imagine it's more a case of differences in FastRam timings. It's not like UAE can truly understand every combination of accelerator card that's out there. Either way it's not a problem, I just don't want to be lulled into a false sense of speed by not continuously testing on hardware. :)

I wonder how racing games like Outrun would look if they used a Stardust 3d tunnel like fixed perspective + some scrolling/panning to create non-fixed-perspective illusion. Would this be hard to hack into cannonball engine just to see how it looks (basically assume ferrari is always in the middle of the "scene" horizontally and then pan towards were it really is)?

With that theoretically the whole background scenery / the track could be pre calculated or even be only some kind of pre-rendered animation. And you'd only have to handle the dynamic objects (cars) per frame. Yeah, there's still the thing with clipping (theoretically a car sprite could end up between scenery objects like trees) but maybe you could get aways with only some very simple fast/clipping were it's hard to notice if every once and then it is not 100 % correct. And/or have some scenery objects (like bushes between roads) handled like dynamic objects.

Maybe a bit more problematic for Outrun (two roads -> horizontally large "scenes" -> panning) than less complex racing games.

well this is shaping up real nicely, so smooth.

is this project in any way in conjunction with the agermose AGA outrun port that is also ongoing? just wondering, not seen it mentioned.

Like Mega Race, more or less.

From videos on YouTube it seems that game misses crucial horizontal scrolling/panning.

I've often thought you could render out track frames from wipeout and render them as an animation using this technique.

Something like Wipeout in theory may be better suited for this technique than Outrun (large required horizontal panning/shifting when there are two roads may end up being too much to look good if perspective is fixed), but otoh it seems in Wipeout there are also jumps/vertical movement, so that may not be good too.