Tempest Xtreem HELP! interminitant lockup when Whoa Sound is played.

[Tempest Xtreem HELP! interminitant lockup when Whoa Sound is played.]

STIMER only resets the voices/Pokey counters.

If you enable Timer IRQs, they operate in continuous mode - STIMER is just a mechanism to allow precise timing.

 

thanks, hadn't realised that. better check some of my code as well!

[Tempest Xtreem HELP! interminitant lockup when Whoa Sound is played.]

Well I hope that's it.

But I'm kinda surprised the original code has problems if there's only the one IRQ on the go. It shouldn't do an IRQ until STIMER has been written and then counted down?

Given the few cycles in between the address setting, I would have thought it would be a pretty rare event for that to screw up.

[Tempest Xtreem HELP! interminitant lockup when Whoa Sound is played.]

another thing to check would be the code for determining whether the VBI has interrupted an IRQ in progress.

bad things can happen if that IRQ is not allowed to finish before a CLI in the VBI allows the next IRQ to happen.

[Newest Tempest Xtreem Video showing Digital voices]

What we decided to go with was try encoding the samples at 5 kHz instead of 4 kHz. It was a trade off, for some added quality and not using much more memory. It was pointed out that I have to clear the interrupt flag right at the beginning of the VBI to allow the Pokey timer to interrupt and play a chunk of the digital sound and set it back right before the RTI. One issue with RMT was I had to enable the interrupt flag right before calling the RMT_PLAY routine or else I get like a buzzing sound. Think it has to do with the way RMT is changing the AUDCTL register. Something I modified in RMT was disabling Voice 4 when a digital sound is in play. I have not really gone over the RMT source in detail and not sure if its possible to use up less CPU time.

 

Your bitrate and quality is controlled by how much CPU usage your game needs and memory. Tempest has to maintain the locations of up to 30 moving objects including the Claw, Enemies, and Bullets that are generated both with a multiplexing PM graphics routine and playfield graphics. Using a graphics 15 screen also causes the Antic chip to steal some cycles also.

 

the game looks awesome, great work!

how does the digital voice sound without anything else going on (no screen, no VBI/DLI's)?

it should be possible to get it to sound almost as good as that state, although it may be very hard if your immediate (stage 1) VBI is large. (Rybags ideas sound good in that case)

 

probably didn't explain very well in my message that you should only check for outstanding IRQ's and clear interrupt flag in VBI if you've disabled the OS VBI and are using your own (which are you doing?). Otherwise sticking the stuff in the deferred (stage 2) allows the IRQ to work again and already does that for you (just as Rybags has already noted)

 

how many scanlines is your immediate (stage 1) VBI taking now Pete? have you moved all you can into deferred (stage 2) VBI (including RMT)? If RMT sounds too slow in stage 2 (IE VBI interrupted IRQ too often) here's some things to try:

 

- try and make the immediate VBI as short as possible and take less time than the time between samples

- you can try and time the IRQ's so they'll always "miss" hitting the VBI, so the sample rate is very important

- if you don't miss the immediate VBI nearly every time, the deferred VBI won't get called enough

- sync the start of the sample playback to a non-DLI scanline so you consistently miss the VBI/DLI's

- try it without RMT to see if that is messing with the AUDCTL clocking on your channel (and screwing with your timer)

 

I use 16-bit timers and 3.9KHz sample to miss the VBI and DLI's, but I don't think that should be necessary, although the 16-bit timer did improve quality a little (but that was more down to missing DLI's not VBI)

 

keep up the good work

[Doctor: A new demo by Trilobit for the Atari 2600]

I've been trying to make a decent video capture for youtube but i need some advice. There're couple of scenes that use 25hz flicker. What would be the best way to mix consecutive frames so that the video would look good at ~25fps?

 

I've had some reasonable results using VirtualDub with the Frame Merger Plugin Filter, although it can sometimes look overly blurry

[Playing Samples]

DamageX... how can i modify the sox commands so it works with your converter4.exe as it seems needs another input format?

 

sox raygun-01.wav -r 4000 -2 -c 1 raygun48.wav

 

-2 makes Sox output 2 byte sample - 16 bit

-c 1 will make sure it is converted to mono if it isn't already

[Playing Samples]

did you ever tried to use DLIs instead of IRQs?

I haven't tried much, but I always thought they could be made to work. There are big problems to work through though.

Unless you do something in a VBI to continue to play samples during vertical blank, you get a nasty sounding 50Hz/60Hz gap of no sample being played during vertical blank. Your display list would probably need to be longer than the recommended length too, because for just a 4KHz sample you need to output a sample every other VCOUNT (every 4 scanlines at 192 resolution). If you miss some samples, or play them at the wrong time, it soon becomes obvious to the ear. Maybe slower samples would work with DLI's though? NRV said he'd got some sample playing going with DLI's in the past.

[Playing Samples]

since you guys are still talking about converting WAVs on the A8... how about a nice dos/windows program to do it in a few seconds instead?

 

http://www.hyakushiki.net/convert4.exe

 

nice! much easier than the GameBoy converter - no need to strip the headers and a lot more progs support 16-bit samples than 8-bit.

 

And, you don't necessarily have to make it XL specific - it should work almost as well by just using the Immediate IRQ vector, and simply disabling all other IRQ types except the Timer you're using.

 

you're right! I should have tried that first as it makes for a more straightforward example. here's the same code but using the OS. (Atari program is sampleOS.exe in the zip file). (remembered to put the Equates file in the zip as well this time)

 

ATARI=0
.include "equates.asm"

; variables

*=$f0

sample 		.ds 2
sample_nybble	.ds 1
sample_value	.ds 1
sample_size	.ds 1
dli_colour	.ds 1


*=$02e0

.byte <run,>run			; initial run address

; main code

*=$2000

run
lda #0
sta NMIEN			; turn off NMI's
sei
sta IRQEN			; disable IRQ's
lda #<irq			; use immediate IRQ vector (no other OS IRQ's will happen)
sta VIMIRQ			; 534
lda #>irq
sta VIMIRQ+1			; 535
lda #<dlist			; set up a display list
sta SDLSTL			; 560
lda #>dlist
sta SDLSTH			; 561
lda #<vbi			; set up an immediate VBI
sta VVBLKI			; 546
lda #>vbi
sta VVBLKI+1			; 547
lda #<dli			; set up a DLI
sta VDSLST			; 512
lda #>dli
sta VDSLST+1			; 513
lda #128+64			; turn on NMI's - DLI's and VBI
sta NMIEN			; 54286
cli				; enable IRQ's	

; initialize sample play irq

play	jsr init			; initialize the sample to play
wait1	lda TRIG0			; any other stuff can go here, but...
beq wait1			; just wait until fire button is pressed
wait2	lda TRIG0			; 
bne wait2
beq play

; end of main code

init
lda #<sample_start
sta sample
lda #>sample_start
sta sample+1
lda #[>sample_end->sample_start]
sta sample_size			; sample size in 256 byte pages
lda #15				; 64KHz pokey clock divided by 16 = 4Khz timer
sta AUDF1			; in timer 1
lda #1
sta IRQEN			; enable timer 1
lda #0
sta sample_nybble		; initialize nybble
ldx #$18
stx sample_value		; an initial sample value (with volume only bit)
lda #115
init1	cmp VCOUNT
bne init1			; sync to a scanline for a precise start
stx STIMER			; start timers (must be non-zero value)
rts

; IRQ

irq
pha				; save a
lda sample_value
sta AUDC1			; play sample ASAP to minimise DMA lag
tya
pha				; save y
ldy #0
lda #1
sty IRQEN			; reset interrupt
sta IRQEN			; re-enable only timer 1
eor sample_nybble		; switch between 0 and 1 (right and left nybble)
sta sample_nybble
beq irq1
lda (sample),y
lsr a
lsr a
lsr a
lsr a				; left nybble of sample
bpl irq2			; always branch
irq1	lda (sample),y
and #$0f			; right nybble of sample
inc sample			; next lo byte of sample
bne irq2
inc sample+1			; next hi byte of sample
dec sample_size			; check if at end of sample
bne irq2			; branch if not
tya
sta IRQEN			; end of sample - reset interrupt
beq irq3			; always branch
irq2	ora #$10			; turn on volume only bit
irq3	sta sample_value		; save sample to play next irq
pla
tay
pla				; restore y and a
rti

; DLI

dli
pha
lda dli_colour
clc
adc #2
sta dli_colour			; just rainbow colours down screen
sta WSYNC
sta COLBK
pla
rti

; VBI

vbi

lda #0
sta dli_colour			; reset dli colour
jmp SYSVBV			; 58463 - do system vertical blank processes

; display list

*=$2400

dlist
.byte $70,$70,$70
.byte $8D+$40,<screen_start,>screen_start
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D
.byte $41,<dlist,>dlist

; sample data

*=$2800

; NB start on a 256 byte page boundary
; sample will stop playing at nearest page boundary if not a multiple of 256 bytes

sample_start
.incbin "raygun44.raw"		; 4KHz, 4-bit raw sample data
sample_end

; screen data

*=$8000

screen_start

 

NB if the DLI's cause sound quality problems you can "waste" another pokey voice to make a 16-bit timer running at 1.79MHz timer to more precisely "miss" the DLI's.

 

[Edit] Unfortunately IRQ's don't seem to be much good if you want to use a lot of DLI's and 192 vertical resolution. Try changing the code to use Antic E instead of Antic D and the DLI's just mess up the timing of the sample playing and it sounds awful. [Another Edit!] Of course it will, because there are no "gaps" for the IRQ to fit into if there are DLI's every scanline. As long as the DLI's are spaced out and not too bunched together, it should be fine.

samplesOS.zip

[Playing Samples]

Nifty.

 

It's amazing though, that aside from your SH, I don't think I've ever seen a game that bothered to attempt to play samples in such fashion, allowing screen updates to proceed normally.

 

From memory, Kennedy Approach ground to a halt, didn't it, when speech was taking place?

 

And, you don't necessarily have to make it XL specific - it should work almost as well by just using the Immediate IRQ vector, and simply disabling all other IRQ types except the Timer you're using.

 

the only one I can think of is Dynakillers, but I don't know if it is using IRQ's. Brilliantly fun game BTW! Of course you do see it in some demos, although they usually don't have DLI's as well.

[Playing Samples]

I've found the following free PC tools helpful to convert to low speed 4-bit samples. I don't know of anything that can do it all in one go though.

 

SoX (Sound eXchange)

This can do most anything with PC sound files! AFAIK PC's never used 4-bit sound samples so it doesn't do that. But it can do everything up to that last step of making into 4-bit. EG from the attached example, I created an 4KHz 8-bit PCM WAV without a header like this:

 

c:\>sox raygun-01.wav -r 4000 -1 raygun48.raw

 

now it just needs converting to 4-bit. It is not too hard to write a program to do that, but it would seem that GameBoy developers have exactly the same problem, and "MegaMan_X" has created a program to do it, which you can get from here:

 

MegaMan_X's GameBoy Wave Converter

 

It's not very sophisticated, but it does the job. NB only 8 character filenames can be used. The input file must be 8-bit mono raw (no header). EG in the attached example I created the 4-bit version of the sound like this:

 

c:\>snd2gbw raygun48.raw raygun44.raw

 

here's some example code that will use an IRQ to play a sample without the OS, showing some DLI's on a blank Antic D screen (ATasm assembler). sample44.exe in the attached zip is the assembled Atari program.

 

[Edit: changed trigger button code to fix buzzing]

 

	ATARI=0
.include "equates.asm"

; variables

*=$f0

sample 		.ds 2
sample_nybble	.ds 1
sample_value	.ds 1
sample_size	.ds 1
dli_colour	.ds 1


*=$02e0

.byte <run,>run			; initial run address

; main code

*=$2000

run
lda #0
sta NMIEN			; turn off NMI's
sei
sta IRQEN			; disable IRQ's
lda #128+32+16+2		; bit 7 on - ram at $5000, bits 4&5 on - 130XE compatible
sta PORTB			; bit 1 on - disable os & rom, bit 0 off - disable basic  
lda #<nmi			; setup custom NMI handler
sta $fffa
lda #>nmi
sta $fffa+1
lda #<irq			; setup custom IRQ handler
sta $fffe
lda #>irq
sta $fffe+1
lda #<dlist			; set up a display list
sta DLISTL
lda #>dlist
sta DLISTH
lda #2+32			; enable normal width screen+screen dma
sta DMACTL
lda #128+64
sta NMIEN			; turn on NMI's - DLI's and VBI
cli				; enable IRQ's	

; initialize sample play irq

play	jsr init			; initialize the sample to play
wait1	lda TRIG0			; any other stuff can go here, but...
beq wait1			; just wait until fire button is pressed
wait2	lda TRIG0
bne wait2
beq play

; end of main code

init
lda #<sample_start
sta sample
lda #>sample_start
sta sample+1
lda #[>sample_end->sample_start]
sta sample_size			; sample size in 256 byte pages
lda #15				; 64KHz pokey clock divided by 16 = 4Khz timer
sta AUDF1			; in timer 1
lda #1
sta IRQEN			; enable timer 1
lda #0
sta sample_nybble		; initialize nybble
ldx #$18
stx sample_value		; an initial sample value (with volume only bit)
lda #115
is	cmp VCOUNT
bne is				; sync to a scanline for a precise start
stx STIMER			; start timers (must be non-zero value)
rts

; IRQ

irq
pha				; save a
lda sample_value
sta AUDC1			; play sample ASAP to minimise DMA lag
tya
pha				; save y
ldy #0
lda #1
sty IRQEN			; reset interrupt
sta IRQEN			; re-enable only timer 1
eor sample_nybble		; switch between 0 and 1 (right and left nybble)
sta sample_nybble
beq irq1
lda (sample),y
lsr a
lsr a
lsr a
lsr a				; left nybble of sample
bpl irq2			; always branch
irq1	lda (sample),y
and #$0f			; right nybble of sample
inc sample			; next lo byte of sample
bne irq2
inc sample+1			; next hi byte of sample
dec sample_size			; check if at end of sample
bne irq2			; branch if not
tya
sta IRQEN			; end of sample - reset interrupt
beq irq3			; always branch
irq2	ora #$10			; turn on volume only bit
irq3	sta sample_value		; save sample to play next irq
pla
tay
pla				; restore y and a
rti

; NMI

nmi
pha
bit NMIST			; check for cause of interrupt
bvs vbi 			; branch if a VBI

; DLI

dli
lda dli_colour
clc
adc #2
sta dli_colour			; just rainbow colours down screen
sta WSYNC
sta COLBK
pla
rti

; VBI

; critical vbi

vbi
sta NMIRES			; reset interrupt
txa
pha				; save x
lda #0
sta dli_colour			; reset dli colour
tsx
lda $104,x
and #$04
bne vbiexit			; exit VBI if VBI interrupted an IRQ
cli				; allow IRQ to interrupt from now on

; deferred VBI here

vbiexit	pla
tax
pla				; restore x and a
rti

; display list

*=$2400

dlist
.byte $70,$70,$70
.byte $8D+$40,<screen_start,>screen_start
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D
.byte $8D,$8D,$8D,$8D,$8D
.byte $41,<dlist,>dlist

; sample data

*=$2800

; NB start on a 256 byte page boundary
; sample will stop playing at nearest page boundary if not a multiple of 256 bytes

sample_start
.incbin "raygun44.raw"		; 4KHz, 4-bit raw sample data
sample_end

; screen data

*=$8000

screen_start

samples.zip

[Space Harrier, OM&TS, Turrican ....]

i think $5caa is the place to look for... I guess in the early demo you haven't used timers? but you have your own IRQ running as at $33xx you run your own routines which writes values to $d205 as well and reads vars from the sample player at $5caa...

 

hmm... so still not get it 100% why i would need 2 routines synced? i mean i can play back samples in a simple loop as well?

 

I wouldn't look at the early demo code, because as you rightly say, there are no timers used. the samples in there are good for ripping of course, but the code is messy and limited to drawing PM graphics and sample playing in a loop. It can't do anything else at the same time which is why I moved on to IRQ's.

 

try the example code which sets up an IRQ first! just think of them as DLI's and you won't go far wrong - except you must reset the timer to stop it being called again as soon as you return, and also set it again to run more than once.

[Space Harrier, OM&TS, Turrican ....]

Hmm,

does Atari 800 emulate the Max-flash cart scheme right now ?!? Or is the game working -as is- on the emulator ?!? I am asking, because a) I never used this emulator and b) I don`t think that thousands of Atarians will buy a Maxflash cart to play SH. And it would be very sad if all your impressive work could be enjoyed only by "a few" Maxflash cart owners...

 

And err, does SH require the full 8Mbit (a full one megabyte) of the Maxflash cart ?!? If not, maybe Fandal could do a nice 320k file version, like he already did with many XEGS carts... Otherwise said: It`s great to see such a wonderful game for the A8 - but it would be very sad if only very few Atarians could really play it in the end... -Andreas Koch.

 

Atari800 based emulators have supported MaxFlash for a couple of years now Not the flashing of the cartridge yet, but only a few things take advantage of that.

 

I don't intend to sell anything (for various reasons), and anything other than a cart would need too much RAM, so MaxFlash seemed the best bet, as people can put it on a MaxFlash if they want to and use it on a normal XL/XE machine

 

My current estimate is that it will use at least 3/4 of the 8Mbit!

[Space Harrier, OM&TS, Turrican ....]

Great work! I really like the fourth level, with the ceiling effect included

(software sprites FTW!). I should have more faith in 15 fps for 3d games from now on..

(do you have some levels running at 20 or more fps at some point?)

 

Best "impossible" port for the (Atari) 8bits by far

 

By the way, how many levels do you think you are going to do? all of them?

 

About the irq's.. I suppose that you have timers in sync with the screen display (so they don't

collide with any DLI or VBI in any frame)? so you need to start the irq's at a specific point the

first time? Many years ago I used DLI's evenly distributed to play sampled music, but it was a

little restrictive about the sampling rates that you can use for the sound

 

NRV

 

some of the later levels will be 20fps, but it struggles to do even a few sprites at 25fps.

 

would like to do all the 18 levels of course!

 

yes, the sync is important with the IRQ's, as is the sample rate. I always thought DLI's might be good for samples too, although I never tried it!

[Space Harrier, OM&TS, Turrican ....]

Sheddy... can you post or send me the POKEY timer sources? as I never played around with pokey timers plus samples. and which is the sample rate?

 

you're missing out on all the fun if you don't do it yourself you know

OK, this is an example that sets up timer 4 without the OS to run at 4KHz and is a good starting point to show basic sample playback

 

; disable IRQ
sei
; point the irq vector to your routine that plays back 1 sample
lda #<irq_play_sample
sta 65534
lda #>irq_play_sample
sta 65535
; we'll assume Pokey clock is set to normal 64KHz and set timer 4 to count to 16 (4KHz sample)
lda #15
sta AUDF4
; enable timer 4
lda #4
sta IRQEN
; enable IRQ
cli
; start timers with a non-zero value
sta STIMER

 

NB apart from playing the next sample, your "irq_play_sample" routine should put 0 and then 4 into IRQEN to reset and re-enable IRQ 4 until all the samples are played.

 

hope that helps

[Space Harrier, OM&TS, Turrican ....]

I forgot to say - thanks for the kind comments everyone! I will hang on to them, as sometimes I can only see the flaws and limitations in the game now, as I've been too close to it for so long.

[Space Harrier, OM&TS, Turrican ....]

Wow !!

Fantastic Great work Chris ! Can`t wait to play SH some day...

Now, how are you gonna release SH when its finished - as a cart image (XEGS, Maxflash,...?) or an XE bootdisk image or what ?!? -Andreas Koch.

 

It will be an 8Mbit MaxFlash image. Anything other than a cart would require a massive RAM expansion, so I'm not looking at doing any other formats.

[Space Harrier, OM&TS, Turrican ....]

That is looking (and sounding) great! I wonder, could the engine be used for other similiar games (OutRun for instance?)

 

It might work for some, but I think the engine would be too slow for OutRun if the road is done properly - I couldn't draw the proper Space Harrier grid on the floor quick enough on the Atari for my liking, and that is a lot simpler than OutRun's road. So I think the character based approach being taken with the current OutRun conversion is probably quite sensible.

[Space Harrier, OM&TS, Turrican ....]

There's a number of ways you could get digi-FX like that.

 

One possibility is to use POKEY timer IRQs - the voice is being used in forced volume anyway, so you can use it's timer without "losing" a voice.

 

Yes, that's how it's being done now, so this is what you should experiment with, Heaven. Although I did find using 2 voices for a more accurate timer helped with unwanted sample noise - that way IRQ's can be timed to miss the critical VBI and DLIS exactly, which otherwise will screw with the timing. Oh, and another tip is not to use the OS IRQ vectors! They seem to add too much delay in determining the cause of the interrupt and again seem to add unwanted noise.

[Space Harrier, OM&TS, Turrican ....]

8 years!

 

Nice to hear from you again though. Updates are good...

 

OK! I've posted an update on the site www.sheddyshack.co.uk and added some movies.

[Space Harrier, OM&TS, Turrican ....]

Maybe you should consult the RMT stuff with Raster, and I believe he will be glad to help with optimizing the player routines to take as low cpu time as possible, and possibly also some size optimizations if they are necessary.

good idea - it's not a major problem, but there's no harm in asking him nicely! (although I can see there is already a lot of optimizing in there already if different features are not used)

[Space Harrier, OM&TS, Turrican ....]

Sheddy, If I were you I wouldn't focus on Stereo RMT tunes for a few reasons:

 

1) stereo pokey is not included in standard machines.

2) stereo music wastes twice as much CPU time as a mono track.

 

Anyway, you'd need two different versions. One with mono music, one with stereo music....as IMO it doesn't make sense to waste cpu time when there's no 2nd pokey anyway.

 

The mono music will have more CPU time left compared to the stereo version. Maybe it's possible to use the extra cpu time of mono version to use more or bigger sprites.

 

Didn't you plan to do different versions for PAL/NTSC?

 

Another thought: Maybe there's a way to do a custom optimalization of the RMT runtime routines...or replace them?

 

you're absolutely right about wasted CPU time if there's no 2nd Pokey. That bothered me a lot, but I found that just patching a few of the loops in the stereo RMT player when there's only a single pokey makes it work at almost the same speed as the mono player. (a slight rewrite of the setpokey routine was also needed to easily patch writing 2nd pokey registers or not)

 

Sal (kjmann) has done the songs as Stereo but they also were designed to sound good if there is only 1 pokey, so no need for different versions combined with the patching.

 

There'll only be one PAL/NTSC version but they'll be pretty much identical due to some compensations

 

I don't fully understand RMT runtime routines, but there were no obvious optimizations when I looked through it, apart from maybe unrolling some loops, which wouldn't make that much difference speed wise, but make it much bigger. Of course assembling with only required FEAT does help a little.

[Space Harrier, OM&TS, Turrican ....]

(another) major graphics engine rewrite to try and minimize slow down with Stereo RMT music has taken a long while

 

wow, what are you optimizing now!? .. you need to start writing tutorials of this stuff (like donlebeau)

 

NRV

 

only that 256 byte wide screen I got rather excited about when discussing your great soft sprites demo posted here last year. I had only just discovered the benefits it would have for space harrier back then, but it took till nearly the end of the year before tools and game code were rewritten completely. (Only about 4-5% frame rate improvement though, which RMT more than wipes out!)

[Gauntlet by Donald R. Lebeau 1984]

Wish I had found this game back in the day - it's fun and really clever (tough though!) - fascinating info about how it works - thanks for sharing, Don.

 

@happymonster

Been familiar with Storm for a while, as you know, but hadn't realised 'till now it was inspired by Gauntletak. Sorry to hear it didn't work out as shareware - it's a really decent game.

[Space Harrier, OM&TS, Turrican ....]

Space Harrier is still alive. No updates on the site though as its pretty minimal news - sorry to disappoint, but (another) major graphics engine rewrite to try and minimize slow down with Stereo RMT music has taken a long while, and I haven't added any extra stages beyond stage 4 yet I don't intend to do that many (news) updates, but now the rewrite is done there should be more visible progress to share over the coming months. It will take as long as it takes, but I will lose my mind if I don't finish this soon - I just realised I've been 8 years doing this multi-colour version now!

[DLI jump instructions]

I believe that I had used chained display lists in some project many years ago

(JVB of DL1 points to DL2, and JVB of DL2 points to DL1..) and it worked, but I

don't know what happens in the emulator

 

I can confirm chained display lists work correctly in Atari800WinPlus 4 at least