Search the Community
Showing results for 'pokey explorer'.
-
Games Not Running! Screen Glitching! Why?
TVisitor replied to SainT's topic in 7800 GameDrive Support
I wrote in to AA to ask, but I a friend directed to this thread, so I might as well try to get visibility. Got my 7800GD. I formatted a 4 gig SD card as FAT32, copied Trebor's pack over and then made sure to "eject" the SD card from Windows to be sure the files were all closed and flushed. When I turn on power, I get the "Saint" boot screen, a message about firmware upgrades (press start to upgrade firmware), then I get dumped into the file explorer. I can't see the highlight bar move, and when I hit fire, all I get at the top of the screen is "./00". If I hit fire 3 times, I'll get "./00./00./00". My 7800 is not modded; the only thing I have done to it is reflow the pads around the RF modulator as they were cracked (My intent is to modify this unit for AV out at some point). I do not have a cable to try the AV out (they are pricey) from the 7800GD. I have tried Dig Dug as a standalone cart, and it boots and I can play on my 7800. I also tried playing Ballblazer on my Concerto cart with the POKEY installed, and it plays fine. I cleaned the cart port for good measure on the 7800 just in case, but no dice. The concerto is using the exact same SD Card that was intended for the 7800GD, just in the size adapter and it seems fine. Thoughts/help? -
Sure, it is not easy. But IIRC years ago debian servers were hacked this way. And it was detected, but not before several people were breached. Sure, that's not MITM, but Man Upfront that creates malicious software in the first place. That's a matter of trust and we trust Tebe. If mads indeed was doing weird things behind our backs and it was found out, that would be the end of Tebe's imago. People also happily run FJC's U1MB firmware or my Pokey Explorer. The latter is open source though, but nobody checks if my .xex is indeed that source Trust. That sounds better. That way, the System Installer also keeps track of which files get installed and it can also be properly uninstalled if needed. That's also one of the reasons why curl|bash should not be used, but a proper package manager, which I assume the system installer is. Haha
-
[RELEASE] RASTER Music Tracker, v1.34.00
VinsCool replied to VinsCool's topic in Atari 8-Bit Computers
In other news while I have been busy for the last couple days with real life stuff mainly, I still managed to find some time to work on RMT and have been able to incorporate a few improvements as well as a few bugfixes since the video preview of the other day. - Fixed the 'jumpy/unstable' playing line in "follow" mode, a bug I know was a thing since forever as far as I could tell. - Rewrote a large portion of the TRACK/SONG drawing function to allow greater flexibility in the display routines, note that currently this looks virtually identical to before, since most of the changes are internal, and intended for greater customisation later, including the "smooth scroll" code I have added in the process. - Added more tuning code that now displays accurately Distortion 4 pitches, tables coming sometime later (thanks synthpopalooza for the initial work for helping me identify the patterns I needed for calculations - Like I said above, a "debug mode" is in the work, which is mostly more infos displayed on screen, and could be toggled from settings - A "POKEY Explorer Mode", which is intended to recreate most of the functionalities of the namesake tool created by ivop, and will become incredibly helpful to track down patterns for creating new pitch calculations formulae, as well as generating new tables in the future. None of what I mentioned has been yet commited to the repository, but this will come soon, I promise this will be worth it- 439 replies
-
- 7
-
-
- raster music tracker
- rmt
- (and 2 more)
-
[RELEASE] RASTER Music Tracker, v1.34.00
VinsCool replied to VinsCool's topic in Atari 8-Bit Computers
Thanks! A lot of trial and error was involved... A lot of errors were produced during that journey But with enough dedication I managed somehow to learn C++ along the way, so It think this was worth it! Hahaha! Just wait for the next commit/version, as well as the updated POKEY plugin incorporating the most recent improvements from Altirra. Can't wait to make the "POKEY Explorer Mode" fully toggleable through the Debug Mode I have been adding to RMT ?- 439 replies
-
- 5
-
-
- raster music tracker
- rmt
- (and 2 more)
-
Hey there, it's been a while since I last posted in this thread. So tonight while I was playing in some of my experimental stuff involving a MIDI controller and Raster Music Tracker, I accidentally discovered what appears to be a POKEY emulation bug involving the 16-bit timing using the AUDCTL Join Channel bits, while also outputting volume on the LSB 16-bit channel (something lovingly nicknamed Reverse-16 Output). How could I describe it and still make sense? Well to make a short description, modulating the 16-bit frequencies, while outputting the sound in the LSB channel outputs a unique kind of tone, and it does have a lot of nice musical application with enough dedication, notably, creating a harmonic tone in a pulse/distortion motion, that would also be exactly 1 octave higher than the actual 16-bit tone underneath, so this is a somewhat predictable effect, making use of the 2 pair of 16-bit channels. Well, here's when things took me by surprise: I noticed the sound output from the ch1+2 and ch3+4 pairs is very different to each others! Specifically, only the ch1+2 pair does seem to sound correct, the other would seem to output the exact same pitch that would be in the MSB 16-bit channel output, and it would also crackle a lot whenever a single POKEY register would receive new data, for some reason. I spent a bit more time earlier tonight to see if this was a normal occurrence, or if I was responsible for the bug in question, and to my surprise, this appears to be a bug present in Altirra for a really long time! I tested versions from the most recent test build, all the way back to 2.80, and as far as I could tell, the behaviour in question (that is, the ch1+2 and ch3+4 pairs having a big disparity in sound output) seems to have been introduced in version 2.90. Version 2.81, 2.80, and most likely further down, did not actually feature this difference, both pairs of channels will sound identical, but unfortunately the emulation accuracy of the Reverse-16 sound is also lower. Also, I did test the exact same setup on real hardware, using both my PAL and NTSC Atari 800xl, and they do not suffer from the disparity-- each pairs of Reverse-16 channels will always sound identical. Same for the Atari800 emulator, it sounds pretty much exactly the same as hardware, in this specific setup. TL;DR: The Reverse-16 output is most likely incorrectly emulated between channels, where CH1+2 is the only one sounding proper, while the other pair is very off. What is expected to happen is that regardless of the 16-bit pairs, the sound should be identical, as far as hardware comparisons went to confirm this was not something I caused myself earlier. --- Anyway, how to reproduce the effect in question? Written below is a simple way to hear what is going on, and this was also how I tested for the disparity going on for every version/platform I tested it, including RMT (where I initially noticed it): - Using POKEY Explorer is the fastest and easiest way to showcase the bug, so first, simply load the .xex in Altirra/hardware/etc - Next, set the 4 AUDF channels to the following frequencies, in this order: $FF, $01, $FF, $01 - Now, press the J and K keys, this will activate the Join Channels 16-bit mode to both pairs, still running in 64Khz mode Once these initial steps are complete, do the following, and you will immediately notice what I am talking about: - Firstly, increment the volume level in channel 1 using the 2 key to a audible level - Next, start decrementing the channel 1's AUDF value using the Q key - What will then happen is the Reverse-16 sound in action, and this should sound exactly as expected The pitch will go higher, while also the pulse wave will change its shape to modulate a different timbre as the frequency is being shifted. - Once you are satisfied of what was heard, lower the ch1 volume back to 0 using the W key, in order to test the ch3 for the same setup - Now, increment the ch3's volume level the same as before, using the 6 key - And just like before, lower the ch3's AUDF using the T key, and listen carefully the sound that will be output From this point onward, 2 things may happen: - The sound produced is exactly the same in either ch1+2 or ch3+4 pairs --EXPECTED Or - The sound produced in the ch3+4 pair is very garbled each time a tiny change is applied, and appears to be identical to the underneath 16-bit tone if it was output the intended way --INCORRECT The second one is exactly what happens in Every Altirra versions I tested, all the way down to the version 2.81, at this point, the 2 channels pairs will sound the same, but with lesser accuracy to what it should sound like on hardware. --- And that's about it, if reading this much text sounds a bit boring, here's the RMT capture I made when I first noticed the behaviour: simplescreenrecorder-2022-05-28_22.04.18-CUT.mp4 While it is not truly the Altirra emulator, I can say for sure this is 100% identical to what the stand alone emulator also did, before I went ahead and gave a more indepth testrun. Also, for further precision, the Altirra emulation core running through the plugins used in this recording came from the version 4.00. So yeah, like I said above, what is expected, and should happen, is that the ch1+2 and ch3+4 output must be identical, fact backed up with hardware tests a few minutes later. Thanks for reading a bit of rambling, I hope this may help tracking down why this is happening.
-
A.R.T.I. (Archaeological Rescue Team International) LATEST DEMO IS AVAILABLE HERE Play on JS7800 HERE A.R.T.I. was released in limited numbers at PRGE2023 and is also available in the VCS store. A.R.T.I. is available in the AtariAge store now! A.R.T.I. is also available on the VCS store for the VCS and a digital version is available A.R.T.I. is inspired by the classic 2600/C64/A8 game H.E.R.O. by Jon Van Ryzin. H.E.R.O. Objective You are Arty's new apprentice. A bunch of explorers and adventurers have got themselves lost in South America and you need to go and rescue them. There are additional on-ROM instructions accessible from the title page. Controls Left & Right - Run / fly left and right. Up - Activate the jetpack Fire 1- Laser Fire 2- Dynamite A.R.T.I. supports SNES2Atari and MEGA7800 to give addition control options and the ability to pause from the controller. Scoring Rescuing a lost explorer or adventurer will earn you 1,000 points. Destroying a wall is worth 75 points Killing any critters or beasties is worth 50 points Bonus points are awarded for each stick of dynamite remaining and for remaining power, when making a rescue. An extra life is awarded at 20,000 points Demo A 10 level demo is available below. Please note the demo is currently designed for NTSC machines and is not fully optimised for PAL machines yet- there may be speed glitches etc. Regular version - Works on real hardware, MiSTer, Dragonfly, BUP, A7800, 7800GD A.R.T.I. Compatibility A.R.T.I. is tested and working great with Dragonfly, GD7800, MiSTer, A7800 V5.2 or better and JS7800 & 7800DS Emulators A.R.T.I works with most Emulators but has some issues with BUP System (Some POKEY notes are off key) and Legacy ProSystem based emulators (some graphical glitches and POKEY notes are off). Plans All done! Credits & Thanks @sramirez2008 @-^CrossBow^- @Trebor for their testing and feedback - fantastic as always! @RevEng for help with compression and answering my never ending stream of questions! @Synthpopalooza for some Pokey Perfection @mksmith for helping to get the tunes into the game! @ZeroPage Homebrew for showing the demo on the stream Media
- 226 replies
-
- 41
-
-
-
[RELEASE] RASTER Music Tracker, v1.34.00
VinsCool replied to VinsCool's topic in Atari 8-Bit Computers
There is a lot of misnomer but you are mostly correct, it's either squarewave or (periodic) noise. There is an actual "sawtooth" waveform that can be generated from the POKEY using the filter and 2 generators at 1.79mhz, however The Atari bass sound? that would be... a periodic noise. I know some people call it sawtooth but that's not what this looks like under an oscilloscope. Ohhh good idea, that would help for explaining, thanks for the suggestion! By far the easiest way to test sounds is by using POKEY Explorer by ivop, a really nice tool which has helped me a lot during my tests. Thank you! That's a pulse wave! this synth technique is usually called Pulse Wave Modulation, or PWM for short. This waveform is also the most characteristic sound used on the SID chip, but the POKEY has its own twist for generating it using the "high pass filter"- 439 replies
-
- 1
-
-
- raster music tracker
- rmt
- (and 2 more)
-
I'm not advocating using this (i.e. stream frames from an IDE device, or a large cartridge like The!Cart), just pointing out it is a possibility that could work. But xxl is all about real hardware, and sizecoding, and so am I. Pokey Explorer works on a 16kb machine. 16kB for the win! Edit: just wait for xxl to release his code, and then listen to the complaints that it doesn't work on their CMOS CPU's because of "illegal" instructions
-
There's no banking. Just loading from storage for each frame. Like Phaeron's IDE video player. That's the beauty of it. ANTIC (yes ANTIC) loads the video RAM directly from the IDE device (or SD card with an IDE API emulated). The CPU just selects a different block out of 16GB every frame, and there's a new frame on your display! Yeah, I recognize the ambivalence. I accept stereo Pokey somewhat, but I am more impressed by single Pokey songs. Extra storage, okay, but where's the limit? 16GB is a Whole Lotta Bytees Co-processor on a cart was well known in the MSX, (S)NES and Sega world, but not so much in our 8-bit time just before that. Only Pokey in some 7800 carts. Wrathchild demonstrated a very cool MODE 7 implementation for the Uno Cart. Yes, I like it. I thought it was about the engine fitting in 16kB, but now I read it should run on a 16kB machine, too That's cool. I really appreciate the effort. Similarly, I made sure that Pokey Explorer runs on a 16kB machine
-
Version 4.00 of my emulator Altirra is out at the usual place: https://www.virtualdub.org/altirra.html As usual, thanks to everyone who tried the releases or just chimed in on just about anything during the 4.00-test series. Never thought I'd been working on it this long, but here's the highlights (it's been about a year since 3.90): Tape: New turbo support, tape editor, and support for loading raw tapes directly from .flac files. Disk: Atari 815 emulation, 8" disk geometry support, Disk Explorer can now access files in Indus CP/M images, many full disk drive emulation fixes. Display: Palette solver, monochrome mode, HDR display support, ANTIC fixes. Sound: Improved audio filtering, automatic output switching when using WASAPI output, POKEY fixes. Input: Preset template generator for making input maps, low-latency paddle option, retuned trackball speeds, 5200 fixes. Devices: Percom AT88-SPD, SIDE 3, 1090 80-column board, Bit 3, virtual FAT16/FAT32/SDFS hard disk; modem, XEP80 and Rapidus fixes. UI: Improved dark mode theme support. Debugger: Memory window upgraded with variable width, type, and graphics decoding support; improved speed, more banked cartridge debugging support, improved 65C816 native mode support, more timestamped logging options, and more verifier options. As usual, 4.00 final is essentially the same as 4.00-test43, except for version number changes and using the release check-update channel. (Previous thread for 3.90/4.00-test) Note that starting with 4.00, Altirra requires at least Windows 7. For Windows XP and Vista users, there is also a 3.91 maintenance release at the above link, which contains backported changes from 4.00 of critical bug fixes and the latest version of AltirraOS. And, per tradition, starting off the 4.10-test series: https://www.virtualdub.org/beta/Altirra-4.10-test1.zip https://www.virtualdub.org/beta/Altirra-4.10-test1-src.7z The device tree now better preserves selection when adding or removing devices. AltirraOS updated to 3.32 with fixes for a couple of compatibility issues with the math pack, so B-Graph and House of Usher now work. Fixes to the docking UI to reduce glitching when switching layouts or toggling full screen mode, due to panes becoming visible too soon and drawing in weird places before being moved to their final location. Fixed a few timing bugs in the standard disk emulator. 810s now produce the head bump sound, the timeout was too short for Record Not Found (RNF) errors, and with long retries the idle timeout was sometimes kicking in too soon. Happy 810 and 1050 now have retuned receive rates. The standard disk emulator now attempts to emulate track buffering for the Happy 810, 1050, and Speedy 1050 profiles, where the drive will burst transmit sectors from memory after reading in new tracks. This makes timing closer to the default modes for those drives. The Happy 1050 commands for toggling track buffering are now also support.
-
I don't consider that Atari either. It's nice during development, but ALL my code runs on real hardware without any enhancements. Sometimes you need 48kB or 64kB, but for example Pokey Explorer runs on an unmodified 600XL with 16kB. It was written last year. You are right in that it is more Atari than an emulator, but for me the charm to retro computing is doing things within the existing limitations. Adding high speed CPU's, even if they are the natural successor to the NMOS 6502, is stretching it IMHO. I don't see the point in running a Spectrum emulator on an Atari that basically sports SNES-like hardware (65c816 + VBXE). Running C64 BASIC and KERNAL on a stock XL (which has been done recently) I think is pretty cool. Or simulating SID on stock hardware. Etc... But each to its own. If @Faicuai wants to add a 1.6GHz ARM CPU that emulates a 6502 on 400MHZ, do not let me stop you
-
Definitely very important work! If it wasn't for Synthpopalooza, I wouldn't have written Pokey Explorer That's almost minimal music. Nice!
-
A song with POKEY sounds, released today!
Probabilitydragon replied to Probabilitydragon's topic in Atari 8-Bit Computers
I was interviewed by Davinder Bedi from London for his youtube show today. I actually talked quite a bit on my ATARI 600XL - and even @ivop and his POKEY explorer are mentioned! -
Hello, since I got back into Atari and discovered the excellent Mad Pascal compiler, I fell into programming again .. so here’s my first Atari program since Atari BASIC programs in the late eighties, also my first pascal program again after .. decades? My target is Ultima V: I was envious in the late 80ies when I saw it at my C64 owning friends - I was impressed by that open world RPG approach!; where I sat at home with my 800 XL without much access to software, fiddling around with some BASIC.. So now - decades later – I can find remedy with the power of Mad Pascal, by writing my own Ultima V port Of course port is a much too big word! It almost certainly will never reach the state of a full game. What you can do is to explore the Lands – an Seas - of Britannia; visit it’s famous towns, mighty castles & picturesque villages! Some basic interaction with the world is possible – rearrange your room, go eat out at one of the many taverns or maybe you care to play 'Stones' on the harpsichord? (See splash screen for the available commands) As I’m in PAL land, I never had the possibility of mode F artifacting on real HW, like it was done in Ultima IV. Also I think that a more colourful approach would be nice: so the idea to use ANTIC mode E for the map viewport, with a 13x10 grid - widescreen! (The original is11 x 11). A tile consist of 12x16 pixel. I converted them from the original assets – available on the net – from 16x16x4c down; and did some basic manual retouching. I’m not good at graphics, so I guess there’s great potential left in the tile design if a real pixel artist would put his hands on that. What I tried though is to make use of “PAL blending” to create a fifth color – grey - and used that for walls, rocks, mountain, .. Another future possibility is to do some PM “augmentation” to the tiles, similar like it is now done for the Avatar tile. Adding red for torches, fires and the like would be an ideal candidate, since it would even look like by design should it flicker The text and info ‘console’ is layout below the map (instead as on the right side like in the original), using mode 2. I extended the displaylist from the standard 192 to 216 scanlines to make more room.. I could only test NTSC with Altirra, where it seems usable still. The attached ATR is a 180K DD mydos disk using xBootDOS. I did not include the original .DAT files that are needed by the program, since I guess that they are still under EA copyright: You would have to copy them by yourself on the disk; I used the files from MSDOS version that GOG offers. The files currently needed are: BRIT.DAT CASTLE.DAT DWELLING.DAT KEEP.DAT TOWNE.DAT (the program will created index files at the first run and tell you if it misses a certain file) I’ll be glad to share the sources and assets if there is interest! (Just needs some clean up first as it grew in all direction while writing and learning) Big thanks to @tebe, @jac!, @gury & @xxl for their development tools that I’m using, and the whole Atariage 8-bit forum for the tons of information I’m getting from here! Thank you! So, what do you think of the idea of doing an Ultima V engine in such a layout? PS: I was looking for pokey conversions of Ultima songs, but could not find any.. maybe someone knows more about that? Music would be a great addition! ULTIMAV_WorldExplorer_v0.01.atr.7z
- 34 replies
-
- 17
-
-
-
meta A new language for the Atari
ivop replied to Kaj de Vos's topic in Atari 5200 / 8-bit Programming
I understand what you mean, but a cross-platform program in C just cannot rely on how the console "should" be. Imagine if every Linux command line utility would mess with my vt100/xterm settings. That's not acceptable. If your program needs shift lock pressed or unpressed, you need to do that in your program (like Pokey Explorer does). If you need printing to E: with a left margin of 0, you set that in your program (midimon does that). A compiler/library combination should not do that behind your back. And neither should a compiler add hidden code to detect whether you were called from a command line DOS or not. That's up to the program itself.- 252 replies
-
- 4
-
-
- programming language
- compiler
- (and 7 more)
-
Sorry about that lol. I have yet to find a way to reduce the noise. I had tried some volume only output in hope that could mask out some of it, and while it did sort of work it also drowned everything else, hahaha. That gives me NES DPCM flashbacks. I was hoping there was some alternatives, tuning the entire table to fit my own is going to be a project anyway so if I can find at least some notes can sound consistent without so much noise it would be nice. The current issue I had was not specifically the lower octaves, I know those couldn't be improved by much, but some random notes that sound significantly noisier even if only a semitone next to another, smooth sounding one. POKEY Explorer, a tuner, a note pad and my poor ears will love this, lol I hope my potential loss of hearing will be worth it, hahaha
-
Yep, I agree with that Raster really did a good job, it's just a bit disappointing how limiting some things were implemented, because the POKEY chip can produce some really amazing sounds. Not lying here, when I did not understand the chip as much I can today, I thought many things were much more limited due to the way RMT was handling them. I assumed high pass filter muted the modulator channel, same with 16-bit, or that the notes available were the only ones possible (and I think I was able to prove there was way more possibilities using custom tuning tables!). So once I could actually know the secrets of the chip, I was pretty much facing a wall of hard coded limitations, that could be worked around manually using AUDCTL settings in instruments and manually playing the frequencies needed using commands 1 and 2, for example, or relying on Speed 1 patterns (Famitracker style!), Or custom tables, as shown by Analmux in RMT patch8, or even my own for tuning purposes, which was only intended as a personal use first but now I think there may be more stuff that could benefit from that, etc having a new tracker which handle do everything RMT could do, but better, with LZSS, means we could do nearly anything, and hopefully having more control over the sounds would make certain things much easier as well, despite being a lot more complex on the get go. note tables for example, are not an exaggeration for that alone, having support for more than 3 hardcoded tables would unlock a lot more power without relying on manually making instruments for 1 specific frequency, and would also avoid having to resort on using hacked versions as well. so if instruments could also change more things on the fly, such as distortion, or AUDCTL alone, plus having support for custom tables, would mean quite a lot of things could be done, and once the hard work is done once for a certain thing (eg, a table of notes for a special setting), that makes things much easier to do once they are available. POKEY Explorer has been incredibly useful for these experiments, so having a tracker that could let the user do nearly the same amount of stuff on the fly to make an instrument could make a huge step forward in creating really impossible sounding POKEY music, I believe
-
I have, it's really awesome stuff, he's been sharing a lot of his research on the Atari Chiptune discord lately, and that stuff was exactly what motivated myself to get a lot further with the POKEY sound generation, and a lot of his own tables had helped me greatly for several of my own tunes already! It's so much fun to create "impossible sounds", even more when it makes sense as to how and why it can be done You're welcome! Yeah I can get ahead of myself too many times, and get lost in some ambitious projects I need to put in stand by simply for either being too difficult to realise (my rambles regarding RMT's implementations of several things is in direct relation to that!), or take so much time that I simply couldn't get it done, or when I manage to, it takes an eternity to complete (the Battle Squadron cover, for example, took me nearly 2 weeks of evenings I had available as free time!), or just get halted to a full stop for a combination of every reasons (Electric City anyone? ). I seriously love POKEY explorer! It truly lets me experiment with sounds so easily, and it has helped so much for my own research regarding frequencies tuning, impossible sounds and very creative sound design too! One of my WIP tunes called "A Permanent Temporary Solution" relied heavily on ideas I got when I was poking around in the program. A Permanent Temporary Solution V2.xex That thing is also unfinished but I think you get the idea behind it It's also one of the few projects that relied on my "hacked up" workflow which consists of manual AUDCTL settings, hacked up instrunents based on serious usage of commands 1 and 2, duplicate instruments, and more instruments, just to get the exact tones and frequencies I needed. And that is the exact kind of projects that make me scream out of (exaggerated) frustration due to being limited by the music tracker itself Thankfully, as Rensoup said: LZSS rules! ?
-
Sure! We'll get there in the future Just listen to Synthpopalooza's exo-area5. Some parts sound almost like a SNES. Somehow I'm "working" on an 800XL keyboard replacement for over a year now So many unfinished projects. But I did Pokey Explorer last year, so not all was lost I like it that you use it, too. Thanks for the compliment the other day. That really means a lot to me.
-
I just looked at the source files you mentioned... damn that looks surprisingly straightforward, I really don't see why there couldn't be any more slots available by the look of it, other than memory concern, but that's not a massive amount of data... right? I can also see vibrato tables (and frankly it looks like it could have more options), a nice implementation of 16 bit (with unique tables for both low and high byte! Clearly there is much more potential for that alone), volume levels table (which is actually something I wish I had known before, it was always annoying to guess proper volume levels being adjusted, I also wonder if there isn't a way to optimise that in order to save precious space to maybe use elsewhere ?)... and then the manual AUDCTL settings, which were the ones I have personally been using in the tracker itself for a while now. Most interestingly, only 3 unique tables for notes, which happen to be 2 bass tables (as C and E), and 1 "pure" table, and each one seem used for several setting, which explains why editing a table breaks other things, that's literally because they're used more than once, and I do know that everything requires a unique table to actually sound good! ? dta frqtabpure-frqtab,$00 dta frqtabpure-frqtab,$20 dta frqtabpure-frqtab,$40 dta frqtabbass1-frqtab,$c0 dta frqtabpure-frqtab,$80 dta frqtabpure-frqtab,$a0 dta frqtabbass1-frqtab,$c0 dta frqtabbass2-frqtab,$c0 So just by the look of it, that makes sense, now I know why several things "broke" from only editing the "pure" table, it is also used in instrument type 0, 2, 4, 8! ? It's pretty clear to me, there are more tables that should exist in the first place... I mean, each ones of these distortions need its own table, otherwise stuff sounds out of tune, or just plain wrong. Another interesting thing I have noticed from my own experiments, thanks to POKEY Explorer, different modes (15khz, 64khz, 1.79mhz), combinations (16-bit, Joined 1+2/3+4, Filter 1+3/2+4, even several things at once!) really produce different results, and so there is simply no way a single table of notes could work for everything, this is the opposite of how it was implemented in RMT! ? And so, that probably sums up my observations, considering the tracker is not open source (to my knowledge), it's really not a great time to hack around, since it's literally going to be required to use several hacked versions to get certain specific things to work, and doing them by hand in the instrument editor is painfully slow for a musician who doesn't know how to code... and just now I realise how handling tuning becomes even more difficult due to its implementation ? To get optimal results, it's clear to me that having a way to load custom notes tables could go a really, really long way, especially if each ones could be used for specific cases. For example, I was able to prove that tuning Distortion A notes to a certain set of frequencies could be improved, and then noticed around the same time that a table working well for 64khz mode will sound weird in 15khz, and vice versa, same for 1.79, or the other distortions themselves, since they pretty much all live with similar behaviours. It looks like everything is there, so clearly editing the player code may be a very easy task, like you said earlier, it's the tracker itself that is pretty much out of reach. I mean even an idiot like myself, who hardly knows any programming, was able to edit the executable to replace the Distortion A table for my own. But this is about as much as I am capable of doing Now, I wonder if I am not getting into a rabbit hole, regarding tuning and other complicated stuff, instead of just trying to make music ? I can clearly see how it good that chip could be, that I am the most definitely certain about! So much potential to understand and make use, hopefully.
-
That would be pretty damn cool! especially considering how the POKEY tuning is limited, it would help a lot on some tunes to achieve the best possible harmonisation The values I theorised here were based on as many notes as possible I could get in-tune to each others, and I believe the same principle also applies to distortions since I got my Distortion C bass to suddenly sound "in-tune" as well, as a side effect, which was unexpected but really welcome. There's still a lot of improvements and most likely more alternative tables that could come into living from this concept, and I do plan to experiment with these for sure, hahah. hopefully I can get a finalised table for $A in both 64khz and 15khz modes that are compatible, so far I was at least able to get a preliminary 15khz table that has the 2 first octaves in-tune to A-4=440, but it will be complicated to use since (at least, RMT) can only use the same table regardless of the mode used. And doing the fine tuning manually in the tracker itself is technically possible, but it's painfully slow and very easy to mess up lol Edit: by the way, I am so thankful for POKEY Explorer, it has helped me so much figuring out tuning and combinations of sounds as well as many more tricks I am starting to use more and more
-
Here's something I'd wanted to do for some time after I did pokey-explorer. This is a spreadsheat with all 16-bit and 8-bit tunings for distortion 10, both PAL and NTSC. You can fiddle with the clocks (these are 800XL clocks), but you can also change the frequence of A4. If you change it to something else, all values automagically change. Everything from Handel's tuning fork at 422.5Hz, Beethoven's fork at 455.4Hz, and everything in between should work All tables are tunes towards 12-TET (12 Tone Equal Temperament). It could be nice to replace the 12-TET column with a different tuning. For example, if you know your song is in D Major, you could put a D Major just intonated table in place, and let the spreadsheet do its magic, and return to pre-Bach just intonation. Like a breath of fresh air. On a G string Atari Tuned Notes A4=x.ods
-
Although I've converted the RMT player, I'm not 100% sure how that table stuff works ? So do you select a Pokey setting, then play all possible frequencies with Pokey explorer and figure out which ones correspond to a note? Then the table is just a compilation of all the valid notes ? With RMT2LZSS it's pretty easy to add tables and patches and even have them all available together although obviously there's no interface (tracker) to select them so it's kind of useless.
-
A few days ago I started doing an experiment related to the tuning itself. I have noticed RMT uses the same standard Distortion A table for both 64khz and 15khz modes. While by itself that isn't a big deal, I eventually noticed that almost everything in 15khz mode was out of tune due to this implementation. So I ran my own attempt at tuning notes directly using POKEY Explorer and a tuner as a reference, then wrote down my own table of notes. Even if not perfect, it's considerably better compared to the original implementation, making octaves 1 and 2 (bass range) a lot less off I think. It's not very easy to make use of it manually, but not impossible either, just takes a bit more time to get it to work without having to hack RMT itself. So here's a quick test I did using one of my own tunes in progress, which was the ideal candidate for that test since it uses mode changes very heavily. Note that I only applied the changes on the bass itself running in 15khz mode, everything else was left unchanged, so it might still sound a bit off as a result. Just compare to the recording in the post just above, I hope this could be a useful improvement over the original out of tune bass (Edit after reloading the page several times: sorry for posting links to an external place, looks like the site is very slow right now and I'm unable to attach files >.<) 15khz tuning table for Distortion A, NTSC: POKEY Table 15khz (A=440hz) V1.txt -> I also learned a bit later synthpopalooza made one before me, which is also almost identical, haha Test tune using the improved 15khz bass tuning (without actually changing the normal 64khz mode): Temple of Questions Tuning Test 6.xex The same tune in progress that was posted in the previous post above, with the lovely 15khz bass being out of tune Sketch 24 v36.xex
-
Could you check if Pokey Explorer runs on a real hardware with 16kB of RAM? I specifically designed this last year to be compatible with a non-upgraded 600XL, but was never able to check it on real hardware.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord