Lotus Esprit Turbo Challenge - STE enhanced (WIP)

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, Doctor Bob Gordon, ICS, Moderator Team

junosix
Captain Atari
Captain Atari
Posts: 331
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by junosix »

Not sure if this is at all helpful but I think I've found where the rev counter is stored. There's a subroutine at $75e30 that at one point clamps a value held at $7cc3c between the values of #$3e8 and #$1f3f and that value is used to pull together data that eventually gets written into the YM registers. What's cool is that those values seem to correspond to real-world rev numbers - idle speed is #$3e8 (1000rpm) and when the car is moving it's between #$6f2 and #$1f3f (1778-7999rpm) rather than it just being an arbitrary counter. Sweet! Code at $70be8 and $70bf2 writes the amplitude to two YM channels so they could be muted there and an STE DMA routine jumped to instead.

I also had a poke around the Amiga version to find the frequency values and the upper and lower frequencies happen to be very close (within a few hundred Hz) to the lowest and highest of the four STE DMA playback frequencies. My guess of there only being 32 different frequency steps was way off though, it's more like 135+. Rounding that down to 128 then considering making the most of using all of the four STE DMA replay frequencies, you could have 32 samples (or however much memory you want to use) going through a quarter of the rev range, then divide down the rev counter to a suitable number that offsets into a table with 128 entries that contain both an STE DMA rate and the start and end address of the rev sample. Something like that should approximate the Amiga engine sound nicely without having to use much CPU time at all.

Hope that makes sense. Still doesn't solve the problem of playing the 1 and 2 player engine sounds simultaneously without extra CPU intervention, mind!
chicane
Atari maniac
Atari maniac
Posts: 90
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by chicane »

AdamK wrote:I think once per line should be enough.
Funnily enough I was poking around the Amiga version the other night, and that uses the copper to switch palette entries to accomplish what you've described. Unfortunately, the use of the Blitter in the changes I've made is already destabilising the existing Timer B rasters (e.g. the one on the horizon) even though I'm using the Blitter in Blit mode rather than Hog mode.
junosix wrote:Not sure if this is at all helpful but I think I've found where the rev counter is stored. There's a subroutine at $75e30 that at one point clamps a value held at $7cc3c between the values of #$3e8 and #$1f3f and that value is used to pull together data that eventually gets written into the YM registers. What's cool is that those values seem to correspond to real-world rev numbers - idle speed is #$3e8 (1000rpm) and when the car is moving it's between #$6f2 and #$1f3f (1778-7999rpm) rather than it just being an arbitrary counter. Sweet! Code at $70be8 and $70bf2 writes the amplitude to two YM channels so they could be muted there and an STE DMA routine jumped to instead.
Thanks for looking into this - it's really helpful! Given that I'm targeting a 1 meg machine, there should certainly be enough memory to do this if I can work it all out. It sounds like you're much more experienced in sound programming than me - I'm somewhat stronger on the graphics side of things! I'm not that bothered about the issue of playing 2 engine sounds simultaneously in 2 player mode (could always revert to the YM if required), but what is playing on my mind is what to do in 1 player mode when the "skidding" sound is playing at the same time as the engine. Software mixing is completely out of the question at the moment - I'm completely starved of CPU time despite using the Blitter to render all roadside objects!

I think part of the reason for this is that I'm now rendering cars and roadside objects to single-pixel granularity so the machine is having to draw an extra 16 pixels on each raster line most of the time to account for the skew. It looks really good but I guess the memory just isn't fast enough. Looks great at 16 Mhz though!
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

chicane wrote: Unfortunately, the use of the Blitter in the changes I've made is already destabilising the existing Timer B rasters (e.g. the one on the horizon) even though I'm using the Blitter in Blit mode rather than Hog mode.!
would be possible to postpone your the BLiTTER's code? I mean, instead of immediate blitting, do only a dump BLiTTER's registers data to a RAM, and do a blitting based on that dump during the bottom border (e.g. in Timer B interrupt after the last visible line)?
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
Frank B
Atari God
Atari God
Posts: 1029
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Frank B »

You could split the blit up and restart it every n lines. It'll be slower but it will allow interrupts to happen. Might be an option. You can use hog mode too.
chicane
Atari maniac
Atari maniac
Posts: 90
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by chicane »

I've spent around a month (on and off) on this project now, and the challenges I'm encountering are somewhat different to what I expected to encounter. I imagined that the big difficulty would lie in isolating the graphics routines I'd need to change and dropping in alternative code to utilise the Blitter. I didn't imagine for a moment that I'd encounter any significant performance issues as a result of doing so.

In reality, the opposite has happened. The changes haven't been that difficult to make, but what I currently have is a game that looks great (with a more detailed road and sprites drawn to single-pixel positions) that runs probably around 60-80% of the speed of the unmodified game. I've gone to reasonable lengths to optimise the new code, but I can't seem to get the desired performance out of the Blitter. It's fair to say that the original routines are well optimised with extensive use of unrolled loops and self-modifying code, but realistically it looks like I might need to look into more fundamental changes to the game code in order to get the desired level of performance.

I can kind of understand why the replacement road routine is slower than the original - in order to draw the road, it's copying 4 bitplanes of data into the logical buffer from elsewhere. The Amiga version is rather more clever - I think it probably clears two bitplanes, and copies only 2 bitplanes, with copperlists (effectively free in terms of CPU time) being used to switch palette entries to render the road lines and rumble strips. I could potentially do something similar to this on the STE with some significant changes to the Timer B code, but would the resulting number of interrupts (probably up to 30 in a single VBL) offset the benefit of copying less bitplanes?

The slowness of the Blitter code to render the cars and trackside objects as compared to the original code is a bit of a mystery. In terms of the amount of data being copied, in most cases there are 4 extra words per line written by the Blitter (to account for the fact that the sprites are now drawn at single-pixel granularity rather than rounding to the nearest 16 pixels). Even with this in mind, it's a bit disappointing that I can't get the Blitter to outperform the existing unrolled loops and self-modifying code. I guess it's a testament to how much work went into optimisation in the original game!

The code I've written to date is at https://github.com/jonathanopalise/lotus-ste if anybody feels like taking a look and feeding back in any way.
Cyprian wrote:would be possible to postpone your the BLiTTER's code? I mean, instead of immediate blitting, do only a dump BLiTTER's registers data to a RAM, and do a blitting based on that dump during the bottom border (e.g. in Timer B interrupt after the last visible line)?
Thanks for your suggestion. It would be a really neat way to have stable interrupts and make use of the Blitter. With respect to Lotus though, it would require some quite large scale re-engineering of the code and I'm not yet at that level of understanding yet :D
Frank B wrote:You could split the blit up and restart it every n lines. It'll be slower but it will allow interrupts to happen. Might be an option. You can use hog mode too.
That's interesting. What do you think would be the benefits and drawbacks of this approach versus using the Blitter in Blit mode?
User avatar
Frank B
Atari God
Atari God
Posts: 1029
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Frank B »

The benefit is that you are in control of the timeslice used by the blitter. It will allow you to use timerb but it will also slow down the blit.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

Frank B, I'm afraid it would add a huge overhead.

The invisible border is very short, less than 100 CPU cycles, therefore in order to keep Timer B interupt 'stable', every BLiTTER's pass should be very short. E.g 32 CPU cycles.

That 32 CPU cycles means for the BLiTTER 8 bus cycles - 2 for bus mastering and 6 for moving data. This 6 means:
A) Plain copy: 3 read source plus 3 write destination - 6 bytes moved.
B) Copy& logical operations: 2 read source, 2 read destination, 2 write destination - 4 bytes move
Plus minimum two "move" instructions to start the BLiTTER's pass - 16 cycles.

Therefore, it that particular case, we use 48 CPU cycles for moving A) 6 bytes; B) 4 bytes.

There is another option, start the BLiTTER in BLiT mode (shared) but in the exact point, where it can fit in the visible area.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
Frank B
Atari God
Atari God
Posts: 1029
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Frank B »

It might be the only option when rasters need to be stable. 64 bus cycles is half a scan line of CPU time. That's too long to be locked off the bus.
If the number of objects is reasonably stable you could blit the first few in hog mode. A 32 pixel sprite is 3 words wide, RMW, RMW, RW. 8 bus cycles with NFSR.
Try two lines at a time.. or 3 per blit and see how it performs.
User avatar
STFormatJez
Atari freak
Atari freak
Posts: 60
Joined: Thu Jun 16, 2011 10:10 am
Contact:

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by STFormatJez »

This is awesome! Lotus Esprit TC was an all-time fave ST game for me, so this is so cool to see!
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

chicane wrote:The code I've written to date is at https://github.com/jonathanopalise/lotus-ste if anybody feels like taking a look and feeding back in any way.
I quickly took a look at this topic.

Game uses 2 VBLs (sometimes 3) for one frame.

When I reduced cars and signs height to 1 by replacing "subq.w #1,D3" (0x5343) with "moveq #1,d3" (0x7601) at address 0x07A538, it was also 2 VLBs.
Therefore something else should be improved first.


---EDIT---
one more observation, on 32MHz CPU still get 2 VBLs
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
chicane
Atari maniac
Atari maniac
Posts: 90
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by chicane »

STFormatJez wrote:This is awesome! Lotus Esprit TC was an all-time fave ST game for me, so this is so cool to see!
Thank you!
Cyprian wrote:
Game uses 2 VBLs (sometimes 3) for one frame.

When I reduced cars and signs height to 1 by replacing "subq.w #1,D3" (0x5343) with "moveq #1,d3" (0x7601) at address 0x07A538, it was also 2 VLBs.
Therefore something else should be improved first.
---EDIT---
one more observation, on 32MHz CPU still get 2 VBLs
Thanks for your observations. You've probably already come to this conclusion yourself (hopefully I've understood you correctly) but I think it's set up to lock to 2 VBLs or 25 frames per second - no more and no less. I think that the code to run the game logic and update the screen manages to run in 2VBLs 99% of the time but occasionally goes to 3VBLs as you've observed.

Unfortunately, it seems that once the game logic code is tied to the graphics update code, so when it regularly starts taking 3 VBLs to draw a frame (as it does with my code updated for the Blitter), the whole game (including the music) slows down accordingly.

I wonder how feasible it would be to decouple the game logic code from the frame update code, with the result being that the game runs at a lower frame rate, but with the benefit of the graphical upgrades? I'm a bit out of ideas with respect to making any further significant performance gains with the Blitter drawing code so I'll need to look at other possibilities.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

chicane wrote:Thanks for your observations. You've probably already come to this conclusion yourself (hopefully I've understood you correctly) but I think it's set up to lock to 2 VBLs or 25 frames per second - no more and no less. I think that the code to run the game logic and update the screen manages to run in 2VBLs 99% of the time but occasionally goes to 3VBLs as you've observed
That 2VLBs is in 50Hz VBL and 3VBLs in 60Hz VBL.
I've observed that limit in Steem Debuger. It has a nice feature - "Run to next VBL".
Also I've just checked Amiga'a Lotus under WinUAE debugger. Regardless of the CPU clock it is also fixed to minimum 2VBLs.

Based on your hints (from github) I found the VBL wait loop 0x07631C - 0x076338. When you set the CPU to 32MHz and change instruction "B07C 0002 cmp.w #$2,D0" to "B07C 0001 cmp.w #$1,D0" at 0x076330, then game will run in 1 VBL.
chicane wrote:Unfortunately, it seems that once the game logic code is tied to the graphics update code, so when it regularly starts taking 3 VBLs to draw a frame (as it does with my code updated for the Blitter), the whole game (including the music) slows down accordingly.

I wonder how feasible it would be to decouple the game logic code from the frame update code, with the result being that the game runs at a lower frame rate, but with the benefit of the graphical upgrades? I'm a bit out of ideas with respect to making any further significant performance gains with the Blitter drawing code so I'll need to look at other possibilities.
I have an idea to postpone gxf code, just by replacing current sprite code with code which dump sprites pointers (like source address, destination address etc.) into a table in ram, and do blitting based on that table, just before "VBL wait loop".

Unfortunately due to business trip I have no time for experiments this week.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
mikro
Hardware Guru
Hardware Guru
Posts: 2218
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by mikro »

Cyprian wrote:Based on your hints (from github) I found the VBL wait loop 0x07631C - 0x076338. When you set the CPU to 32MHz and change instruction "B07C 0002 cmp.w #$2,D0" to "B07C 0001 cmp.w #$1,D0" at 0x076330, then game will run in 1 VBL.
Hmm, this is interesting. When I was trying Lotus III on Falcon/CT2@50 MHz I could swear the game ran at 1 VBL all the time. So either Ppera has changed this limitation or Lotus III doesn't have it anymore or I'm just blind. ;-)
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

I would not be surprised, Pera is very smart guy.

---EDIT---
I've just checked "Lotus III - The Ultimate Challenge (1992)(Gremlin)[cr ICS][t].st".
There is the same VBL waiting loop with 2VBL limit at 0x7402A "B07C 0002 cmp.w #$2,D0".
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2182
Joined: Sun Jul 31, 2011 1:11 pm

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Eero Tamminen »

Cyprian wrote:I've observed that limit in Steem Debuger. It has a nice feature - "Run to next VBL".
In Hatari you could do the same by setting debugger breakpoint for VBL change:

Code: Select all

> b VBL ! VBL

CPU condition breakpoint 1 with 1 condition(s) added:
	VBL ! VBL
-> Track value changes, show value(s) when matched.
and continuing emulation:

Code: Select all

> c
Returning to emulation...
  $745
1. CPU breakpoint condition(s) matched 1 times.
	VBL ! VBL

CPU=$e007d6, VBL=1861, FrameCycles=128, HBL=0, LineCycles=128, DSP=$0
$00e007d6 : 52b8 0466                          addq.l    #1,$0466.w

> c
Returning to emulation...
  $746
1. CPU breakpoint condition(s) matched 2 times.
	VBL ! VBL

CPU=$e007d6, VBL=1862, FrameCycles=136, HBL=0, LineCycles=136, DSP=$0
$00e007d6 : 52b8 0466                          addq.l    #1,$0466.w

> c
Returning to emulation...
  $747
1. CPU breakpoint condition(s) matched 3 times.
	VBL ! VBL

CPU=$e007d6, VBL=1863, FrameCycles=132, HBL=0, LineCycles=132, DSP=$0
$00e007d6 : 52b8 0466                          addq.l    #1,$0466.w
While STEEM provides nice GUI for above, with Hatari one can trivially profile where time goes between debugger invocations.

Just by build your program with debug symbols and enable profiling before continuing:

Code: Select all

> profile on
Profiling enabled.
chicane
Atari maniac
Atari maniac
Posts: 90
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by chicane »

Cyprian wrote:
I have an idea to postpone gxf code, just by replacing current sprite code with code which dump sprites pointers (like source address, destination address etc.) into a table in ram, and do blitting based on that table, just before "VBL wait loop".

Unfortunately due to business trip I have no time for experiments this week.
Sorry for the delay, I've been meaning to reply for some time!

I think what you've described (postponing the gfx code) would be that difficult to implement. What would be the purpose of doing this though - would it somehow improve performance (thus enabling everything to be drawn within 2VBLs), or is it a measure to stabilise the Timer B rasters somehow? Or something else entirely?

Sorry if I'm missing something obvious - I know you're a lot more experienced in these things than I am!
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

the purpose was 1) to improve performance by the BLiTTER usage; 2) move the BLiTTER code to the bottom/top border area, so as not to interfere the Timer B interrupts (stable rasters)

I dug around a bit and realised that could not be to easy to implement that. There are three Timer B interrupts per frame. 1st visible line - change colors for the first player, 99 visible line - change colors for the second player, and the last one in 199 line. Two first are short (1 or two lines), the third one fires a huge code and occupies almost whole bottom border.

One more, the game uses ineffective joystick/keyboard management. Instead of pooling IKBD once per frame, it uses ACIA interrupt with huge code. That interrupt is fired four times for receiving ONE joystick packet.
In additional the MFP interrupts are software ending :)
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
junosix
Captain Atari
Captain Atari
Posts: 331
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by junosix »

If you're shooting for 1MB machine then would it be plausible to use pre-shifted sprites rather than the blitter for placement to get breathing space for the timer routines?

I had a go at one possible way to do the engine sound with low CPU use, uses about 150KB though! Use Spacebar to accelerate.
You do not have the required permissions to view the files attached to this post.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

nice routine.

actually Lotus I works fine with 512KB ST.
I have extracted a 512KB memory snapshot, and I've prepared a loader for it.
It allows me to load a snapshot to the RAM, run my patch code and start Lotus on any ST compatible machine with 1MB or more RAM.
Now I have a small problem with ACIA. Sometimes joystick doesn't work, sometimes just fire button. When I fix that I'll post it here.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

Attached you can find my Lotus snapshot (binaries and sourcecode) loader for 1MB ST. It leaves upper 512KB RAM for patches.

LZ4 decoder is by Anima from there

As you can see I've added as an example a sky gradient (in MODECODE.s file - it is dedicated for patches).
Schowek-4.png
Works fine on Steem, I have some problems with keyboard/joystick under Hatari and I didn't checked on real hardware.

Eero Tamminen wrote:
Cyprian wrote:I've observed that limit in Steem Debuger. It has a nice feature - "Run to next VBL".
In Hatari you could do the same by setting debugger breakpoint for VBL change:

Code: Select all

[/quote]
Eero, would be possible to check somehow a current status of ACIA and IKBD under debugger? I stuck somewhere with ACIA.
You do not have the required permissions to view the files attached to this post.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
chicane
Atari maniac
Atari maniac
Posts: 90
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by chicane »

junosix wrote:If you're shooting for 1MB machine then would it be plausible to use pre-shifted sprites rather than the blitter for placement to get breathing space for the timer routines?
It's a thought yes - I suspect it would (sadly) be faster than using the Blitter. Although it would still be slower than the implementation in the unmodified game, because unless the sprite is drawn at ((x&15)==0), another four words per line need to be drawn to take account of the horizontal shifting of the sprite.
junosix wrote:I had a go at one possible way to do the engine sound with low CPU use, uses about 150KB though! Use Spacebar to accelerate.
This sounds absolutely amazing! I guess 150K isn't that big a problem if we're talking about a 1 meg machine - it still leaves lots of space for other enhancements. I notice that the steps between sounds are quite large at lower rev counts - would it use a lot more memory to reduce these steps?
Cyprian wrote:Attached you can find my Lotus snapshot (binaries and sourcecode) loader for 1MB ST. It leaves upper 512KB RAM for patches.

LZ4 decoder is by Anima from there
As you can see I've added as an example a sky gradient (in MODECODE.s file - it is dedicated for patches).
I'm really glad you've come up with this loader system - I'm comfortable with the idea of building patches but couldn't really work out how to build a self-loading version of the game that would incorporate my patches. The best I could think of was to have two programs in the AUTO folder, with the first one loading the required content above 512k, and the second one being a hex edited version of the original Lotus executable to incorporate my changes. I wasn't sure if this would be considered a "dirty" approach though.

The sky gradient looks amazing, and you've managed to do it without compromising the speed of the gameplay.

I notice the snapshot crashes after the race completes. Would it be feasible to run the full game using this loader system - i.e. capture the snapshot at the intro screen of the game, and have the game behave as per the original game following that point?

I'm wondering if it would be worth setting up a Github/Bitbucket repo in an attempt to combine the work done by the three of us into something we can share with the community?

I'd love to help with the ACIA issue by the way but I'm not so familiar with that area of the ST.
junosix
Captain Atari
Captain Atari
Posts: 331
Joined: Sun Jul 08, 2007 3:22 pm
Location: Plymouth

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by junosix »

Glad you like the engine sound! Happy to sort the other sound effects too if wanted.

There are some lines in that source I commented out (lines 61, 105, 107, 121, 122, 124, 126 and 138), if they're uncommented you'll get more steps but it's a bit clicky because it has to restart the sample, otherwise it does sound okay. Whereas with fewer steps it just changes the sample when the last one has finished playing (therefore it takes longer to do that at lower revs because the sample is longer). See what you think sounds best. The problem is that without being able to mix in realtime there doesn't seem to be an easy way to accurately cut into a higher/lower rev sample at the same position as the currently-playing sample. I tried doing it by monitoring the sample address counters in the DMA chip and calculating the offset into the next sample but it wasn't accurate enough and gave a sort of doppler effect when moving through the revs.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1949
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Cyprian »

@chicane your approach sounds good, more generic and could be better for the final version.
Mine was prepared just for testing purposes. Do a patch and easily/quickly test it and measure its impact onto the game.
It bombs out due to lack of inserted floppy - just put "Lotus III - The Ultimate Challenge (1992)(Gremlin)[cr ICS][t].st" into A during the game.

Github is a nice idea.

@junosix after uncommenting those lines for me it sounds ok.
Maybe on the lower pitch, the difference between steps are a bit to high.
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2182
Joined: Sun Jul 31, 2011 1:11 pm

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by Eero Tamminen »

Cyprian wrote:Eero, would be possible to check somehow a current status of ACIA and IKBD under debugger?
There's no debugger "info" sub-command for showing their state yet, but maybe a a debugger script showing relevant IO-register values would help a bit?

For example output of this script:

Code: Select all

# --- ikbd.ini ---
# ACIA IKBD SR/TR
m 0xfffc00-0xfffc01
# ACIA IKBD RDR/TDR
m 0xfffc02-0xfffc03
Would look like this in the debugger:

Code: Select all

> parse ikbd.ini
Reading debugger commands from 'ikbd.ini'...
> m 0xfffc00-0xfffc01
00FFFC00: 83 00 05 00 02 00 00 00 00 00 00 00 00 00 00 00   ................
> m 0xfffc02-0xfffc03
00FFFC02: 05 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
User avatar
metalages
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 146
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: Lotus Esprit Turbo Challenge - STE enhanced (WIP)

Post by metalages »

junosix wrote:Glad you like the engine sound! Happy to sort the other sound effects too if wanted.

There are some lines in that source I commented out (lines 61, 105, 107, 121, 122, 124, 126 and 138), if they're uncommented you'll get more steps but it's a bit clicky because it has to restart the sample, otherwise it does sound okay. Whereas with fewer steps it just changes the sample when the last one has finished playing (therefore it takes longer to do that at lower revs because the sample is longer). See what you think sounds best. The problem is that without being able to mix in realtime there doesn't seem to be an easy way to accurately cut into a higher/lower rev sample at the same position as the currently-playing sample. I tried doing it by monitoring the sample address counters in the DMA chip and calculating the offset into the next sample but it wasn't accurate enough and gave a sort of doppler effect when moving through the revs.
Maybe you can use the blitter to do the mix mike i do here https://github.com/gibs75/demOS/blob/ma ... /README.md
Would probably be in between in terms of performance.
Post Reply

Return to “Games - General”