Shop OBEX P1 Docs P2 Docs Learn Events
Console Emulation - Page 57 — Parallax Forums

Console Emulation

15253545557

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!

  • roglohrogloh Posts: 5,280
    edited 2024-05-23 00:38

    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)

  • pik33pik33 Posts: 2,358
    edited 2024-05-23 07:51

    I also had one of those Gravis Ultrasound cards

    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
    
  • evanhevanh Posts: 15,386

    @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.

  • evanhevanh Posts: 15,386
    edited 2024-05-23 09:51

    @evanh said:
    ... the flexibility of four independent DMA channels ...

    And no synth hardware included. That forced new software tooling.

  • @evanh said:

    @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.

  • evanhevanh Posts: 15,386

    @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

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-24 23:37

    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.

  • roglohrogloh Posts: 5,280
    edited 2024-05-25 00:18

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-25 00:27

    @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)

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-25 02:29

    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:

    • changed HBlank flag timing to bandaid some timing problems (owie ouch)
    • fixed mosaic priority bug
    • fixed mosaic for 8bpp and hires modes
  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-25 22:52

    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.

  • roglohrogloh Posts: 5,280
    edited 2024-05-26 03:08

    @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.

  • @rogloh said:

    @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?

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-26 22:14

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-27 20:54

    So here it is:

    • 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.

  • Cool...Pitfall had some minor flickering when fading to black between screens...gone now. Lemmings mid-screen flickering is also gone 👍

  • @avsa242 said:
    Cool...Pitfall had some minor flickering when fading to black between screens...gone now. Lemmings mid-screen flickering is also gone 👍

    Good to hear.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-06-03 00:20

    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?? :D ). 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

  • @avsa242 said:
    Just tried this...it looks and sounds awesome (where's that P2 arcade cabinet at?? :D ). 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.

  • evanhevanh Posts: 15,386
    edited 2024-06-04 00:12

    @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?

  • @evanh said:

    @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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-06-27 00:58

    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 :)

Sign In or Register to comment.