ivop

February 3

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.

February 3

13 minutes ago, Probabilitydragon said:

A value of 80 / $50 in AUDCTL corresponds to channel 2 joined to 1 and channel 1 clocked @1,79MHz AFAIK 🤔

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.

February 3

48 minutes ago, xxl said:

if anyone is interested in the unShrinkler decompression procedure for Atari 6502, I have shared it here:

https://xxl.atari.pl/shrinkler-decompressor/

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.

February 2

2 hours ago, thorfdbg said:

All existing already .. see above. Os++ has a faster FP ROM, a DOS and a DUP, all in the regular 16K ROM.

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 😕

February 2

7 hours ago, Rybags said:

The interrupt thing - maybe not such a big problem, just replicate the handlers in each bank.

For me the obvious thing to have with a >16K OS would be a built in Dos with minimal Ram footprint. And a decent monitor as well. Just between those two you might be looking at most of the Rom space used (also noting you'd have to replicate the built in character sets and possibly the FP Rom portion).

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

February 2

10 hours ago, gnusto said:

There's no way PAQ8 would run an Atari (1288MB of memory used for this lol) but that should be the lowest you can get this for comparison in a *general compressor* - PAQ is a consistent winner in compression efficiency among math fiends who are fascinated by this stuff and always testing.

Yep, that's Prediction by Partial Matching (PPM) I mentioned earlier

My xz example also uses a lot of memory. Around 900MB

February 1

3 hours ago, Wrathchild said:

68000 might be nice target, but higher level stuff such as a JVM or .NET (Core) might be a problem without an MMU assisting with memory allocation

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

February 1

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.

February 1

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.

February 1

9 minutes ago, xxl said:

https://www.cpcwiki.eu/forum/programming/modified-shrinkler-without-parity-context/
Shrinkler: 1412 (no parity)

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

February 1

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

February 1

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

February 1

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?

February 1

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.

January 31

15 minutes ago, flashjazzcat said:

Unfortunately not. Until the config is locked, the BIOS setup menu ROM is fixed in the OS ROM address space.

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,

15 minutes ago, flashjazzcat said:

Locking the config is essential anyway, since bad things could otherwise happen because of accidental writes to the control registers in the PIA address range (the registers disappear when once the configuration is locked, to become visible again when RST is pulled low).

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?

15 minutes ago, flashjazzcat said:

The address space contention between code and data in extended banks can be a big problem, for sure. That's the main reason I decided to put my GOS on a bank switched cartridge. Of course this assumes you want or need to use extended RAM banks for data too, which may not be the case. Careful placement of code and data can still overcome these limitations, though (see SDX drivers which place the majority of their code in extended RAM, but are still able to work with data in the extended RAM banking window).

Yes, the banking scheme and minimal code in main RAM used by SDX is a work of art

January 31

3 hours ago, flashjazzcat said:

My first thought it that you cannot programatically switch between the four OS ROM banks on the U1MB unless you are the setup menu. Only the reset line being pulled low allows the configuration to be unlocked, which is a pre-requisite for switching ROM banks.

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?

Quote

There's no real reason you couldn't use extended RAM banks for a similar purpose, though; SDX already greatly extends the core functionality of the machine via drivers which may reside almost wholly in extended RAM banks.

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

3 hours ago, Wrathchild said:

potentially stack work would be needed as interrupts occurring when different banks are switched in need also to push the current bank so that it can be restored before returning control to it

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.

January 31

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

January 31

12 hours ago, BoroPaul said:

So I have no idea what you did here!

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

January 30

41 minutes ago, BoroPaul said:

You are absolutely correct.. I must have made a mistake when I ripped it into WAVs. DOH.
Appreciate the effort, apologies for my mistake.

No worries. Glad we figured out what was wrong.

41 minutes ago, BoroPaul said:

I would still love an actual SAP rip of the XEGS version!!

Do you have a link to a binary or an ATR or something?

41 minutes ago, BoroPaul said:

In the mean time here is a stereo MP3 of Jet Set Willy.

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.

January 30

13 hours ago, BoroPaul said:

Is there is another version? Or is the ASMADB sap the 7800 track? Or did you accidently dupe 2 over to 4?

Again, I am not being negative, I am incredibly grateful that you did this for me., it is just very, very odd!!

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.

January 28

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

Ballblazer.sap

January 27

9 minutes ago, Mclaneinc said:

Total horror stories I'm afraid...Machines just ruined in a blink of an eyelid..

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.

January 27

18 minutes ago, Mclaneinc said:

Don't want to worry but that seems to be an ingot PSU in the last picture..Can't be 100% but it deffo looks like one..

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

January 26

4 hours ago, makary said:

Ha ha! Yeah, getting through all the ads is a kind of challenge. Anyway, keep in mind that witamina C is of no less importance

https://www.youtube.com/watch?v=XNfp7s1atAw&feature=emb_imp_woyt

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