ivop

Once ListInUse is set, you can use INC and DEC to switch between 0 and 1. You Display Lists are page aligned, so storing the LSB every VBI is not needed (it's always zero). You can probably drop the ListInUse variable completely. Keep the display lists page aligned. One on an even page, the other on an odd page. LDA sdlstl+1 , AND #1, branch, set new sdlstl+1.

Yes. Press J and A. Then set AUDF1/AUDC1/AUDF2/AUDC2 to 00 A0 28 AA. There's your tone. 28 is the MSB, 00 is the LSB. channel 1 is silent, channel 2 has volume.

Nice code. Fun to see how you keep Y at 0 whenever it needs to be 0, and it's 0 again after the mulitply. And there's no ldy #0 anywhere in the code Not a geat fan of the @ usage for branches (@- and @-1) and rol @ (and I don't like it that I can't type a single @ on atariage without triggering the username lookup ) But as I said, nice code. Looking forward to where this goes in terms of usage in the future.

But if I'm not mistaken, you took out the PBI code, isn't it? PBI code really is necessary these days. And wouldn't you like to have 10-12kB extra ROM space (for each extra bank) to enhance the current OS? HATABS can hold up to 12 drivers! But alas, there's no hardware support 😕

I believe I said similar things in the first post But FP ROM is a good call! As for a built-in DOS/DUP and monitor, that's a great idea! Perhaps @candle can incorporate a new feature in the PBI device he's creating (U1MB+SIDE3+...) where one can leave the OS bank select register unlocked, and perhaps the BASIC bank selection, too, which could lead to bigger languages in an 8kB window. I have read @phaeron 's U1MB implementation, and if that's how the hardware currently works, I see no way around it. It seems 32-in-1 OS is not emulated by any of the emulators, and I'm having a hard time finding its programming documentation

Yep, that's Prediction by Partial Matching (PPM) I mentioned earlier My xz example also uses a lot of memory. Around 900MB

Agree on the higher level stuff. Those VMs have all sorts of curly braces languages and OO support that goes way beyond what we (might) need. About the M68K, if I'm not mistaken, all opcodes are 32-bits. That's quite a lot to handle for an 8-bit emulator. I was thinking more along the lines of the lowest supported ARM Thumb instruction set with 16-bit opcodes. But hoping for a possible candidate that would require even less loads from memory for the common opcodes

Another test: $ asapconv -o bla.xex Ballblazer.sap $ atari800 bla.xex $ altirra bla.xex Altirra consistently plays the same song. atari800 on the other hand switches between two variations seemingly random between various calls. It could be nice to run this routine through siddasm2 and see how it works.

Same thing as 7zip, but with xz, and no arhive header overhead: $ ls -l foo.gfx -rw-r--r-- 1 ivo ivo 7680 Feb 1 20:57 foo.gfx $ xz -9 -Fraw -S.raw -v --lzma1=dict=4096,lc=1,lp=0,pb=0,mode=normal,nice=132,mf=bt4,depth=0 foo.gfx foo.gfx (1/1) 100 % 1,458 B / 7,680 B = 0.190 $ ls -l foo.gfx ls: cannot access 'foo.gfx': No such file or directory $ ls -l foo.gfx.raw -rw-r--r-- 1 ivo ivo 1458 Feb 1 20:57 foo.gfx.raw $ xz -d -Fraw -S.raw -v --lzma1=dict=4096,lc=1,lp=0,pb=0,mode=normal,nice=132,mf=bt4,depth=0 foo.gfx.raw foo.gfx.raw (1/1) 100 % 1,458 B / 7,680 B = 0.190 $ ls -l foo.gfx.raw ls: cannot access 'foo.gfx.raw': No such file or directory $ ls -l foo.gfx -rw-r--r-- 1 ivo ivo 7680 Feb 1 20:57 foo.gfx LZMA also requires quite a lot of memory. So far, I think shrinkler is the way to go. Perhaps throw a bunch of .car and .xex files at all of those compressors with a shell script/batch file, and see how they perform on real Atari 8-bit data.

Nice link. It has the source of the compressor, and it compiles on Linux, too!

I think it's not a "fair" comparison. You cannot compare single file compressors with archivers. An archiver has way more overhead, like storing paths and filenames. Also, there's only one sample file, which is the Conan title screen. PPM (Prediction by Partial Matching) is currently state-of-the-art compression, but it's very memory hungry. Example of the overhead of an archiver: $ 7z a -t7z -m0=lzma -mx=9 -mfb=64 -mmf=bt4 -mlc=1 -mlp=0 -mpb=0 bla.7z test.gfx ... Archive size: 1575 bytes (2 KiB) ... $ 7z l bla.7z ... 2021-02-01 18:44:46 ....A 7680 1453 test.gfx ...

It just occurred to me that asapconv probably starts playing the SAP file with predictable random numbers. I just checked, and asapconv renders the exact same WAV file everytime. That's not how it should be. Edit: I just checked Altirra. If I run it from the command line, like altirra Ballblazer.sap, it's exactly the same everytime. But if I run it from within altirra again with File->Open Image, it plays a different tune! But it still doesn't vary after re-opening the "image".

Hi all, Another one of my brainfarts. I'm in the mood For years, I have been thinking how nice it would be to have a virtual machine running on the Atari 8-bit that treats the whole U1MB banked RAM as a continuous address space. Virtual machine can be read as something from a BASIC interpreter with 1MB of tokenized source code, up to a full blown CPU emulation with a 1MB address space. In any case, it'll be a lot slower than native code, but I think the speed of compiled BASIC for example, could be reached. Now there are two options I thought about. 1. Design a new VM/CPU that is specifically designed to run as fast as possible on a 6502. Pro: it'll be fast, Con: you need to create a new compiler backend that targets this VM/CPU. 2. Find a current compiler backend (gcc, llvm, ...) that has an easy enough instruction set to emulate. Pro: the backend is already there, Con: even as a bare bones compiler without library support, you are stuck with a predefined calling convention which is probably not optimal for a 6502 implementation. In both cases, one could implement INT like interrupt instructions that delegate slow parts to a dedicated routine in 6502 assembly outside the VM's address space. This way, a decently fast standard library could be created. Whadd'ya think?

Some more thoughts. Perhaps a custom U1MB firmware could leave the OS select register unlocked, but reflashing the firmware is not easily done for everybody, and hence will severly limit the spread, and use of a potential new 32kB OS. How about the 32-in-1 Maxflash upgrade? I have no idea how that one works. Can one switch banks while in operation? Downside of this approach is that it won't work together with U1MB, and the 32-in-1 cannot be flashed by the Atari itself, so you have to have some other means to (re)flash new ROMs.

Oh, that's a pitty. I was hoping that the configuration registers, or at least the OS ROM switch register, could be left unlocked. Even though as you say, accidental writes could mess things up. But I guess proper behaving software should not be a problem, i.e. if they don't use mirror locations? Yes, the banking scheme and minimal code in main RAM used by SDX is a work of art

I suppose the setup menu locks the configuration registers upon exiting, but could it also leave them unlocked so they can still be changed later on? I think it could be nice having them in ROM, without having to load or copy them to RAM, and they won't apear in the middle of your RAM space when its code is toggled on and off. One could include phaeron's fast XEP80 driver for example in the extra ROM space that becomes available. Or other E: drivers, possibly selectable from your setup menu. Or various P: drivers. Or D : drivers for joystick port connected harddisks. And so on... The idea is to keep all the interrupt code the same in both banks which would mean it doesn't matter which bank is switched in. Only the rest of the OS might be different for a while when the userspace application does a CIO call.

Hi all, Has anybody ever considered creating a larger OS than the current 16kB? With the ability to programatically switch between four OS banks on the U1MB, one could easily consider them a pair of 32kB OSs or even one big 64kB OS Let's consider a 32kB OS. The second bank should have the RESET vector redirected to select the first bank. Both charsets should be present. All the interrupt code. Perhaps some more. After that, you can reuse large parts of the second bank for other code. A driver in bank one can switch banks at a certain point in memory, continue execution in the second bank, switch back at the right memory location, continue execution in bank one again, and return to the userspace program. Any thoughts on this? Regards, Ivo

This is the only difference betweeen Ballblazer.sap from ASMADB, and the patched version: 17,18c17,18 < 0000200 30 35 3a 32 36 2e 38 34 32 20 4c 4f 4f 50 0d 0a < 0 5 : 2 6 . 8 4 2 sp L O O P cr nl --- > 0000200 36 35 3a 32 36 2e 38 34 32 20 4c 4f 4f 50 0d 0a > 6 5 : 2 6 . 8 4 2 sp L O O P cr nl Note that I only changed $30 to $36, so that's actually one nibble

No worries. Glad we figured out what was wrong. Do you have a link to a binary or an ATR or something? Interesting how you process the resulting audio. It sounds a lot more vivid than the mono version, and it does not sound like just fake stereo widening.

The only thing I did is take the SAP file you said contained the right first song, and hexedited 05:xx.xxx to 65:xx.xxx Edit: which player do you use? $ asapconv -o bla.wav Ballblazer.sap $ mpv bla.wav Playing: bla.wav (+) Audio --aid=1 (pcm_s16le 1ch 44100Hz) AO: [alsa] 48000Hz mono 1ch s16 A: 00:00:22 / 01:05:26 (0%) Exiting... (Quit) I definitely hear the fourth channel slowly increasing in volume. Edit2: altirra plays the .sap file fine, too.

Here's a version that plays 65 minutes instead of 5. Ballblazer.sap

Hey, you changed your avatar picture, even though just today you told us all you don't like your picture being taken Looking good, grumpy old man But indeed, so far it went OK with the ingot PS, but it can suddenly fail and take all your RAM with it. If you're lucky.

Yeah. The sticker on top seems missing, but the overall shape looks like an ingot!

Wow, thank you for this link! It's hard to believe this was a song made in 1972 Okay, this remaster is bit snappier, but that's it. The drumming is amazing! 1972 Album version: https://www.youtube.com/watch?v=8QgOGl5Oes0 Live in '72: https://www.youtube.com/watch?v=NTFFhcEus5o And now I have to listen to the rest of their discography

Absolutely! And don't forget to take your witamina D