Also, got sound effects working in the Tempest 2000 port. Main thing missing now is MOD player and cleaning up some odds and ends (like aforementioned line clipping oddities). And oh wow MOD is a pretty Smile format. Each pattern is an entire kilobyte!
MOD files were so cool back in the day. I never experienced them in their full Amiga glory as I was a PC guy then but remember how much better 90's games that used them sounded vs our MIDI audio games. The problem with MIDI was that unless you were all decked out with high end Roland MT-32 synth gear etc you never seemed to have the right patches vs what the gamedevs had authored and it sounded thin/cheesy in comparison to MOD music, especially on board synths such as Adlib FM stuff. I know later Soundblasters improved this over time and started including nicer GM wavetable patches etc, but MOD music just had this cool sound in comparison. I also had one of those Gravis Ultrasound cards at one point which sounded decent with MOD files, though it was less well supported until later. See after 5:10 here for an example of using it and onwards for music it played.
A lot of the difference there is really ideological. The Amiga people were just built different. Even discounting the common use of generic GM patches, even many PC games that are hardcoded for Adlib/YM3812 really aren't so hot. Interestingly some of the best AdLib music I'm aware of originates with semi-obscure PC-98 to IBM ports. Not entirely sure what to attribute that to. Maybe most of the western AdLib drivers are just insufficent in a way PMD isn't? See https://vgmrips.net/packs/pack/princess-maker-2-pc#17-battle for a particular example of very atypical AdLib/YM3812 sound. Mmmh that feedback distortion.
The actually interesting oddity though is why an Atari Jaguar game uses Amiga MOD files for music. One presumes that it's because the format is relatively simple and they could use existing tools. I want to say the Jaguar DSP is capable of something better (it runs at ~29 MHz !). Maybe 8 channels with ADPCM compression (so like a crunchier SNES)
I still have a GUS. Good old classic - .pat files are documented somewhere so a .mid player using GUS patches should be possible. A new format to add to my multiformat player
Edit:
The GF1 Patch files are multipart sound files for the Gravis Ultrasound
sound card to emulate MIDI sounds in high quality. Each Patch can consist
of many samples (for example, a string ensemble consists of Violin, Viola,
Cello, Bass) which are played depending on the note to play. A patch can also
contain a part to be played before the loop and a part to be played after
the tone has been released.
OFFSET Count TYPE Description
0000h 12 char ID='GF1PATCH110'
000Ch 10 char Manufacturer ID
0018h 60 char Description of the contained Instruments
or copyright of manufacturer.
0054h 1 byte Number of instruments in this patch
0055h 1 byte Number of voices for sample
0056h 1 byte Number of output channels
(1=mono,2=stereo)
0057h 1 word Number of waveforms
0059h 1 word Master volume for all samples
005Bh 1 dword Size of the following data
0060h 36 byte reserved
Following this header, the instruments with their headers follow.
An instrument header contains the name and other data about one
instrument contained within the patch.
OFFSET Count TYPE Description
0000h 1 word Instrument number. ?Maybe the MIDI instrument
number?. In the Gravis patches, this is 0, in
other patches, I found random values.
0002h 16 char ASCII name of the instrument.
0012h 1 dword Size of the whole instrument in bytes.
0016h 1 byte Layers. Needed for whatever.
0017h 40 byte reserved
About the patch, I don't know anything. Maybe somebody could enlighten me.
Each patch record has the following format :
OFFSET Count TYPE Description
0000h 7 char Wave file name
0007h 1 byte Fractions
0008h 1 dword Wave size.
Size of the wave digital data
000Ch 1 dword Start of wave loop
0010h 1 dword End of wave loop
0012h 1 word Sample rate of the wave
0014h 1 word Minimum frequency to play the wave
0016h 1 word Maximum frequency to play the wave
0018h 1 dword Original sample rate of the wave data
001Ch 1 int Fine tune value for the wave
001Eh 1 byte Stereo balance, values unknown**
001Fh 6 byte Filter envelope rate
0025h 6 byte Filter envelope offse
002Bh 1 byte Tremolo sweep
002Ch 1 byte Tremolo rate
002Dh 1 byte Tremolo depth
002Fh 1 byte Vibrato sweep
0030h 1 byte Vibrato rate
0031h 1 byte Vibrato depth
0032h 1 byte Wave data, bitmapped
0 - 8/16 bit wave data
1 - signed/unsigned data
2 - de/enable looping
3 - no/has bidirectional looping
4 - loop forward/backward
5 - Turn envelope sustaining off/on
6 - Dis/Enable filter envelope
7 - reserved
0033h 1 int Frequency scale, whatever that means
0035h 1 word Frequency scale factor
0037h 36 byte Reserved
@Wuerfel_21 said:
A lot of the difference there is really ideological. The Amiga people were just built different.
Come on, it's the hardware first and foremost. The trackers were borne of the flexibility of four independent DMA channels - Opening up PCM for everything, while not imposing mixing requirement on any processor.
The actually interesting oddity though is why an Atari Jaguar game uses Amiga MOD files for music. One presumes that it's because the format is relatively simple and they could use existing tools. I want to say the Jaguar DSP is capable of something better (it runs at ~29 MHz !). Maybe 8 channels with ADPCM compression (so like a crunchier SNES)
That's down to the Amiga tracker tools being like mini-studio workstation tools. Perfectly adequate for games, and long time in the public domain probably helped too. Not to mention the team was Ex-Amiga developers. It was a painless path.
@Wuerfel_21 said:
A lot of the difference there is really ideological. The Amiga people were just built different.
Come on, it's the hardware first and foremost. The trackers were borne of the flexibility of four independent DMA channels - Opening up PCM for everything, while not imposing mixing requirement on any processor.
That's what I was getting at though: The Amiga sound chip isn't really much better than others (in hindsight, anyways. For A1000 in 1985 vs. a bunch of basic PSGs it's pretty good, for the 5 people who bought the A1000.). It's only 4 channels and each PCM instrument eats up lots of RAM. People on average just use it better.
Anyways, MOD player is at the point where it makes vaguely melodic noises. I really love how the sample start addresses are completely implicit. Each sample starts at $43C + (highest_used_pattern_number +1)<<10 + sum_of_all_previous_sample_lengths. Very cool and not at all obnoxious.
@Wuerfel_21 said:
It's only 4 channels and each PCM instrument eats up lots of RAM. People on average just use it better.
Sure, more than four channels would've been nice, but those channels also did get used as intended. One doesn't build such sequencing flexibility into the hardware if the idea was to just stream PCM like a CD.
MOD player now vaguely works. Missing effects etc, still need to work on it. Also some of the sound volumes are really off. Anyways, I finally managed to put something in version control: https://github.com/Wuerfel21/tempest2k Will get it's own thread when it's in actually presentable state. See instructions in README. Other than that, usual config nonsense is in src/p2config.spin2. Preconfigured for EC32MB with USB on 16 and VGA/sound on 24. If you want to sniff the janky PSRAM-sourced MOD+sound effect code, it's in mikodsp.spin2. Ditto mikoobj.spin2 and mikogpu.spin2 for the gfx stuff. yak.s is the main game logic, now full of .if ^^defined PROPELLER lines. Notable: if you manage to copy t2000p2.dat onto the parallax flash filesystem, it is capable of loading it from that (see p2config). By default it's set up for 9P, which is mega slow but convenient for development
Just found a great sinkhole of timing problems in MisoYume: The PPU's rendering starts 88 master cycles after hblank ends. So register updates that happen in the first 88 cycles of a scanline should contribute to rendering. Have to rethink CPU/PPU sync a bit, not sure how. For now, just turning the hblank flag in HVBJOY on a bit sooner seems to fix some issues (but probably causes others somewhere). The value I already had was too soon anyways. Current: 300 cycles. Correct: 268 cycles. New and improved formula: 330 cycles.
Yeah I noticed some timing problems in the first scanlines at the top of a frame where they were flickering quite a lot. I think you may have mentioned this before. Sometimes there were corruptions in the middle of the screen too where the graphics on the line are being offset randomly and were showing up in the wrong position horizontally from where they should be although that was just one game IIRC. If I see it again I will let you know which game it was.
@rogloh said:
Yeah I noticed some timing problems in the first scanlines at the top of a frame where they were flickering quite a lot. I think you may have mentioned this before. Sometimes there were corruptions in the middle of the screen too where the graphics on the line are being offset randomly and were showing up in the wrong position horizontally from where they should be although that was just one game IIRC. If I see it again I will let you know which game it was.
Those are just the same old "CPU cog can't keep up" problems. I still haven't gotten to (re)write the relevant code bits (bypassing the generic rk_read8 function for DMA and instruction fetch). Partially because cog RAM is super full, so I need to make it slower first by kicking out the opcode table to hub RAM.
The glitched positions happen because the scroll registers are write-twice. Between the two writes the state becomes invalid, so if the PPU decides to start rendering in that exact moment, the scanline becomes glitched. This only really happens with FastROM games.
The issues I am talking about happen even when the CPU is keeping up (if you ever got to the first boss in P&R, the translucent text box it speaks in is a good one - the HUD has a similar issue where the first scanline can start to flash, but this never happened in any released version, just an observation from playing with values)
Also, just tracked down another annoyingly obtuse bug: high priority tiles are not correctly displayed when mosaic is active because the priority bit gets masked away in-place in the same register that's used to carry mosaic over a 4-pixel group boundary. (you can see this in zelda during the screen transition when you enter the forest) oops... I think I can fix it, but I'll need to update a bunch of unrolled code and associated skip tables and it'll be a few cycles slower.
EDIT: It's not so bad. each pixel needs two extra instructions for masking now, but the 5 instructions masking the layers in place per-group are removed, so there's only 3 more instructions per group, i.e. 1.5 cycles lost per-pixel
Also, I fixed some other mosaic issues while I was at it (should now work correctly for hires and direct color modes)
So, finally looking into the code queuing. So moving opcode execf table to hub RAM surprisingly didn't make anything much worse, but now the trouble that I put off is re-emerging, which is that the memory map is very odd and changes between cartridges, which makes loading a logically contiguous block a minor nightmare. Might need to load even more annoying overlay sections. Oh bother.
@Wuerfel_21 said:
So here it is, the next minor update after which I'll surely attack one of the major issues:
changed HBlank flag timing to bandaid some timing problems (owie ouch)
fixed mosaic priority bug
fixed mosaic for 8bpp and hires modes
This version feels like has improved some games when I did a quick run through. By the way Lemmings which was the game where I saw that horizontal offset part way down the screen seems to be performing a bit better now but is still not fixed in that area. Tried that Donkey Kong Country game again too to see if it helped but graphics are corrupted badly.
@Wuerfel_21 said:
So here it is, the next minor update after which I'll surely attack one of the major issues:
changed HBlank flag timing to bandaid some timing problems (owie ouch)
fixed mosaic priority bug
fixed mosaic for 8bpp and hires modes
This version feels like has improved some games when I did a quick run through. By the way Lemmings which was the game where I saw that horizontal offset part way down the screen seems to be performing a bit better now but is still not fixed in that area. Tried that Donkey Kong Country game again too to see if it helped but graphics are corrupted badly.
Does it? It really should only improve ones that use mosaic or a particular kind of raster effect.
ION, I managed to fix the code queuing (some nice off-by-one issues), but inexplicably it made everything hugely slower. So maybe it doesn't really work yet?
Ok, the reason it appeared to slow everything down is that I forgot to update the cycle counter for code fetches, so it tried to run more instructions per scanline than it should. With code queuing properly working, CPU timing should now have lots of wiggle room.
With a fastROM game in what I presume to be a spin loop, going through generic reads was ~17k cycles per scanline. New version does it in ~10k. Bugged version without cycle tally took ~24k.
I see some nasty bugs now though. Will have to work through all those before I can release a new version. Compatibility regression would be super lame.
EDIT: Some of these bugs are SPC700 timing related, so I guess I really need to do all the major reworkings right now (SPC timing fix would cause audio crackling when the CPU is late, so DMA optimization must come first). Wolf3D though seems to not work with the new opcode queue at all regardless of timing, so let's fix that first!
Implemented 65816 code queuing (should fix/reduce flickering lines in many FastROM games)
Fixed alignment of CGRAM raster effects
Note that there's some compatibility regression. Quintet games in particular don't work anymore due to how their sound driver is. They were a bit flakey before.
Tempest 2000 port now has mostly ok audio. The warp stage music really requires interpreting the finetune nibble because otherwise the drum loop ends too early. I have no idea why or how finetune is supposed to work, but whatever I came up with kinda works. Also, I added a sound test menu to easily play all the music and effects. Code still lives at https://github.com/Wuerfel21/tempest2k
Ideal default for gamepad controls I'm still unsure about...
Work has been slow due to an, uh, overflow condition. Not directly affecting us, but cause for concern nonetheless.
Just tried this...it looks and sounds awesome (where's that P2 arcade cabinet at?? ). I don't think I ever played a port/emulation of Tempest that had music. Shame...it really seems to deserve the high-energy music this has.
It did seem to lock up (music still chugging along though) after about 5min the second try. P2 gets pretty warm though (heatsink on either side of the edge board) and it's also pretty warm today here (27C).
Minor nitpick: the github readme says the build target for the binary is t2000p2.binary - in the Makefile it looks like it's actually supposed to be t2000p2.bix though. That built without any issue.
@avsa242 said:
Just tried this...it looks and sounds awesome (where's that P2 arcade cabinet at?? ). I don't think I ever played a port/emulation of Tempest that had music. Shame...it really seems to deserve the high-energy music this has.
It's basically 1:1 to the Atari Jaguar version of Tempest 2000, with some minor bug fixes (and probably some new bugs). I want to add some of the cut music tracks back into the game (as is the later levels eventually repeat the music). They're already in the sound test menu. Though there's still some playback bugs in some of them.
It did seem to lock up (music still chugging along though) after about 5min the second try. P2 gets pretty warm though (heatsink on either side of the edge board) and it's also pretty warm today here (27C).
Oh bother. Maybe RAM delay isn't quite right, try tweaking that etc.
Minor nitpick: the github readme says the build target for the binary is t2000p2.binary - in the Makefile it looks like it's actually supposed to be t2000p2.bix though. That built without any issue.
oopsie, fixed. I renamed it at some point for nebulous reasons.
@Wuerfel_21 said:
Work has been slow due to an, uh, overflow condition. Not directly affecting us, but cause for concern nonetheless.
That's cryptic. Flooding?
Yea. Happening everywhere down here. Towns nearby got evacuated. Seems to be fine around here, but we lifted valueables off the basement floor just to be sure.
Comments
Also, got sound effects working in the Tempest 2000 port. Main thing missing now is MOD player and cleaning up some odds and ends (like aforementioned line clipping oddities). And oh wow MOD is a pretty Smile format. Each pattern is an entire kilobyte!
MOD files were so cool back in the day. I never experienced them in their full Amiga glory as I was a PC guy then but remember how much better 90's games that used them sounded vs our MIDI audio games. The problem with MIDI was that unless you were all decked out with high end Roland MT-32 synth gear etc you never seemed to have the right patches vs what the gamedevs had authored and it sounded thin/cheesy in comparison to MOD music, especially on board synths such as Adlib FM stuff. I know later Soundblasters improved this over time and started including nicer GM wavetable patches etc, but MOD music just had this cool sound in comparison. I also had one of those Gravis Ultrasound cards at one point which sounded decent with MOD files, though it was less well supported until later. See after 5:10 here for an example of using it and onwards for music it played.
A lot of the difference there is really ideological. The Amiga people were just built different. Even discounting the common use of generic GM patches, even many PC games that are hardcoded for Adlib/YM3812 really aren't so hot. Interestingly some of the best AdLib music I'm aware of originates with semi-obscure PC-98 to IBM ports. Not entirely sure what to attribute that to. Maybe most of the western AdLib drivers are just insufficent in a way PMD isn't? See https://vgmrips.net/packs/pack/princess-maker-2-pc#17-battle for a particular example of very atypical AdLib/YM3812 sound. Mmmh that feedback distortion.
The actually interesting oddity though is why an Atari Jaguar game uses Amiga MOD files for music. One presumes that it's because the format is relatively simple and they could use existing tools. I want to say the Jaguar DSP is capable of something better (it runs at ~29 MHz !). Maybe 8 channels with ADPCM compression (so like a crunchier SNES)
I still have a GUS. Good old classic - .pat files are documented somewhere so a .mid player using GUS patches should be possible. A new format to add to my multiformat player
Edit:
The GF1 Patch files are multipart sound files for the Gravis Ultrasound sound card to emulate MIDI sounds in high quality. Each Patch can consist of many samples (for example, a string ensemble consists of Violin, Viola, Cello, Bass) which are played depending on the note to play. A patch can also contain a part to be played before the loop and a part to be played after the tone has been released. OFFSET Count TYPE Description 0000h 12 char ID='GF1PATCH110' 000Ch 10 char Manufacturer ID 0018h 60 char Description of the contained Instruments or copyright of manufacturer. 0054h 1 byte Number of instruments in this patch 0055h 1 byte Number of voices for sample 0056h 1 byte Number of output channels (1=mono,2=stereo) 0057h 1 word Number of waveforms 0059h 1 word Master volume for all samples 005Bh 1 dword Size of the following data 0060h 36 byte reserved Following this header, the instruments with their headers follow. An instrument header contains the name and other data about one instrument contained within the patch. OFFSET Count TYPE Description 0000h 1 word Instrument number. ?Maybe the MIDI instrument number?. In the Gravis patches, this is 0, in other patches, I found random values. 0002h 16 char ASCII name of the instrument. 0012h 1 dword Size of the whole instrument in bytes. 0016h 1 byte Layers. Needed for whatever. 0017h 40 byte reserved About the patch, I don't know anything. Maybe somebody could enlighten me. Each patch record has the following format : OFFSET Count TYPE Description 0000h 7 char Wave file name 0007h 1 byte Fractions 0008h 1 dword Wave size. Size of the wave digital data 000Ch 1 dword Start of wave loop 0010h 1 dword End of wave loop 0012h 1 word Sample rate of the wave 0014h 1 word Minimum frequency to play the wave 0016h 1 word Maximum frequency to play the wave 0018h 1 dword Original sample rate of the wave data 001Ch 1 int Fine tune value for the wave 001Eh 1 byte Stereo balance, values unknown** 001Fh 6 byte Filter envelope rate 0025h 6 byte Filter envelope offse 002Bh 1 byte Tremolo sweep 002Ch 1 byte Tremolo rate 002Dh 1 byte Tremolo depth 002Fh 1 byte Vibrato sweep 0030h 1 byte Vibrato rate 0031h 1 byte Vibrato depth 0032h 1 byte Wave data, bitmapped 0 - 8/16 bit wave data 1 - signed/unsigned data 2 - de/enable looping 3 - no/has bidirectional looping 4 - loop forward/backward 5 - Turn envelope sustaining off/on 6 - Dis/Enable filter envelope 7 - reserved 0033h 1 int Frequency scale, whatever that means 0035h 1 word Frequency scale factor 0037h 36 byte ReservedCome on, it's the hardware first and foremost. The trackers were borne of the flexibility of four independent DMA channels - Opening up PCM for everything, while not imposing mixing requirement on any processor.
That's down to the Amiga tracker tools being like mini-studio workstation tools. Perfectly adequate for games, and long time in the public domain probably helped too. Not to mention the team was Ex-Amiga developers. It was a painless path.
And no synth hardware included. That forced new software tooling.
That's what I was getting at though: The Amiga sound chip isn't really much better than others (in hindsight, anyways. For A1000 in 1985 vs. a bunch of basic PSGs it's pretty good, for the 5 people who bought the A1000.). It's only 4 channels and each PCM instrument eats up lots of RAM. People on average just use it better.
Anyways, MOD player is at the point where it makes vaguely melodic noises. I really love how the sample start addresses are completely implicit. Each sample starts at $43C + (highest_used_pattern_number +1)<<10 + sum_of_all_previous_sample_lengths. Very cool and not at all obnoxious.
Sure, more than four channels would've been nice, but those channels also did get used as intended. One doesn't build such sequencing flexibility into the hardware if the idea was to just stream PCM like a CD.
MOD player now vaguely works. Missing effects etc, still need to work on it. Also some of the sound volumes are really off. Anyways, I finally managed to put something in version control: https://github.com/Wuerfel21/tempest2k Will get it's own thread when it's in actually presentable state. See instructions in README. Other than that, usual config nonsense is in src/p2config.spin2. Preconfigured for EC32MB with USB on 16 and VGA/sound on 24. If you want to sniff the janky PSRAM-sourced MOD+sound effect code, it's in mikodsp.spin2. Ditto mikoobj.spin2 and mikogpu.spin2 for the gfx stuff. yak.s is the main game logic, now full of
.if ^^defined PROPELLERlines. Notable: if you manage to copy t2000p2.dat onto the parallax flash filesystem, it is capable of loading it from that (see p2config). By default it's set up for 9P, which is mega slow but convenient for developmentJust found a great sinkhole of timing problems in MisoYume: The PPU's rendering starts 88 master cycles after hblank ends. So register updates that happen in the first 88 cycles of a scanline should contribute to rendering. Have to rethink CPU/PPU sync a bit, not sure how. For now, just turning the hblank flag in HVBJOY on a bit sooner seems to fix some issues (but probably causes others somewhere). The value I already had was too soon anyways. Current: 300 cycles. Correct: 268 cycles. New and improved formula: 330 cycles.
Yeah I noticed some timing problems in the first scanlines at the top of a frame where they were flickering quite a lot. I think you may have mentioned this before. Sometimes there were corruptions in the middle of the screen too where the graphics on the line are being offset randomly and were showing up in the wrong position horizontally from where they should be although that was just one game IIRC. If I see it again I will let you know which game it was.
Those are just the same old "CPU cog can't keep up" problems. I still haven't gotten to (re)write the relevant code bits (bypassing the generic rk_read8 function for DMA and instruction fetch). Partially because cog RAM is super full, so I need to make it slower first by kicking out the opcode table to hub RAM.
The glitched positions happen because the scroll registers are write-twice. Between the two writes the state becomes invalid, so if the PPU decides to start rendering in that exact moment, the scanline becomes glitched. This only really happens with FastROM games.
The issues I am talking about happen even when the CPU is keeping up (if you ever got to the first boss in P&R, the translucent text box it speaks in is a good one - the HUD has a similar issue where the first scanline can start to flash, but this never happened in any released version, just an observation from playing with values)
Also, just tracked down another annoyingly obtuse bug: high priority tiles are not correctly displayed when mosaic is active because the priority bit gets masked away in-place in the same register that's used to carry mosaic over a 4-pixel group boundary. (you can see this in zelda during the screen transition when you enter the forest) oops... I think I can fix it, but I'll need to update a bunch of unrolled code and associated skip tables and it'll be a few cycles slower.
EDIT: It's not so bad. each pixel needs two extra instructions for masking now, but the 5 instructions masking the layers in place per-group are removed, so there's only 3 more instructions per group, i.e. 1.5 cycles lost per-pixel
Also, I fixed some other mosaic issues while I was at it (should now work correctly for hires and direct color modes)
So here it is, the next minor update after which I'll surely attack one of the major issues:
So, finally looking into the code queuing. So moving opcode execf table to hub RAM surprisingly didn't make anything much worse, but now the trouble that I put off is re-emerging, which is that the memory map is very odd and changes between cartridges, which makes loading a logically contiguous block a minor nightmare. Might need to load even more annoying overlay sections. Oh bother.
I think I implemented all the annoying parts, but of course it doesn't actually work. Some logical error somewhere. Great.
This version feels like has improved some games when I did a quick run through. By the way Lemmings which was the game where I saw that horizontal offset part way down the screen seems to be performing a bit better now but is still not fixed in that area. Tried that Donkey Kong Country game again too to see if it helped but graphics are corrupted badly.
Does it? It really should only improve ones that use mosaic or a particular kind of raster effect.
ION, I managed to fix the code queuing (some nice off-by-one issues), but inexplicably it made everything hugely slower. So maybe it doesn't really work yet?
Ok, the reason it appeared to slow everything down is that I forgot to update the cycle counter for code fetches, so it tried to run more instructions per scanline than it should. With code queuing properly working, CPU timing should now have lots of wiggle room.
With a fastROM game in what I presume to be a spin loop, going through generic reads was ~17k cycles per scanline. New version does it in ~10k. Bugged version without cycle tally took ~24k.
I see some nasty bugs now though. Will have to work through all those before I can release a new version. Compatibility regression would be super lame.
EDIT: Some of these bugs are SPC700 timing related, so I guess I really need to do all the major reworkings right now (SPC timing fix would cause audio crackling when the CPU is late, so DMA optimization must come first). Wolf3D though seems to not work with the new opcode queue at all regardless of timing, so let's fix that first!
Ok, I am big stupid and forget to exclude RAM in banks 7E/7F from being treated as ROM, it's all better now.
So here it is:
Note that there's some compatibility regression. Quintet games in particular don't work anymore due to how their sound driver is. They were a bit flakey before.
Cool...Pitfall had some minor flickering when fading to black between screens...gone now. Lemmings mid-screen flickering is also gone 👍
Good to hear.
Tempest 2000 port now has mostly ok audio. The warp stage music really requires interpreting the finetune nibble because otherwise the drum loop ends too early. I have no idea why or how finetune is supposed to work, but whatever I came up with kinda works. Also, I added a sound test menu to easily play all the music and effects. Code still lives at https://github.com/Wuerfel21/tempest2k
Ideal default for gamepad controls I'm still unsure about...
Work has been slow due to an, uh, overflow condition. Not directly affecting us, but cause for concern nonetheless.
Just tried this...it looks and sounds awesome (where's that P2 arcade cabinet at??
). I don't think I ever played a port/emulation of Tempest that had music. Shame...it really seems to deserve the high-energy music this has.
It did seem to lock up (music still chugging along though) after about 5min the second try. P2 gets pretty warm though (heatsink on either side of the edge board) and it's also pretty warm today here (27C).
Minor nitpick: the github readme says the build target for the binary is t2000p2.binary - in the Makefile it looks like it's actually supposed to be t2000p2.bix though. That built without any issue.
Cheers
It's basically 1:1 to the Atari Jaguar version of Tempest 2000, with some minor bug fixes (and probably some new bugs). I want to add some of the cut music tracks back into the game (as is the later levels eventually repeat the music). They're already in the sound test menu. Though there's still some playback bugs in some of them.
Oh bother. Maybe RAM delay isn't quite right, try tweaking that etc.
oopsie, fixed. I renamed it at some point for nebulous reasons.
That's cryptic. Flooding?
Yea. Happening everywhere down here. Towns nearby got evacuated. Seems to be fine around here, but we lifted valueables off the basement floor just to be sure.
Anyways, some procrastination later, I have finally fixed the line clipping (and some audio more oddities) in the T2K port. It's almost ready to go!
Of course the fix is something stupid like this: https://github.com/Wuerfel21/tempest2k/commit/d21bb6e00c2ad4aaf785248b4998e8c1ce801004
Oh cool...just noticed that it'd saved my score from last time