-
Content Count
2,282 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by ivop
-
RMT2LZSS: convert RMT tunes to LZSS for fast playback!
ivop replied to rensoup's topic in Atari 8-Bit Computers
And only a couple of extra scanlines for 100Hz, 150Hz and 200Hz. @rensoup what about 240hz? I could have tried it myself, but 'winetricks dotnet45' takes ages -
3-D Printable Atari 8-bit Cartridge Holder
ivop replied to Bill Lange's topic in Atari 8-Bit Computers
I experienced the same problem. My solution was to increase the width-axis to 105% before slicing. 110% was too big. -
I've been working on my 600XL Winter Restoration Project
ivop replied to bfollowell's topic in Atari 8-Bit Computers
I didn't think they were labels, but I thought they were painted. Or was it a different process to get the lettering on the keycaps? But it's good to hear they survived! Once I cleaned my microwave front panel with a "soap" that removed the digits and icons within a single wipe -
I've been working on my 600XL Winter Restoration Project
ivop replied to bfollowell's topic in Atari 8-Bit Computers
I have put a case of an 800XL and a 1050 in the dishwasher with acceptable results, but with the lettering removed and glued back later. Never done any keys. Hopefully the lettering will survive the detergent. Perhaps try a single (spare?) key first to see how it goes. -
I see. I forgot about the ROM portion So in theory, up to graphics 7, the screen memory could live above the BASIC ROM, and then you have 1-4kB extra space below the BASIC ROM? Set RAMTOP above the ROM, call graphics 7, then set RAMTOP back to below the ROM. Could that work?
-
I suppose not if you do what baktra said: The display list and screen memory should end up at $CC00 instead of $BC00, and ?FRE(0) shows the extra 4096 bytes.
-
Sorry, I misinterpretted that. Update on the aforementioned family that got together at christmas, grandpa and grandma are possitive, too. So that's 7 out of 8. The 8th one was actually the first to be tested, because she had a cold. Tested negative twice (with five days in between). She was lucky. @Heaven/TQA yeah, 9 months is incomprehensible...
-
I don't think you can be vaccinated if you are already ill. Nevertheless, let's hope he recovers without too many lasting effects! After that, he could get vaccinated. It appears that immunity by disease is shorter than immunity by vaccin. Not 100% validated yet, though. Indeed, if Jason reads this forum, I don't know him, but wish him all the best!
-
I was wrong, it was rapper Jebroer ("Yourbrother"), not Boef. Here's a clip: https://www.nu.nl/285213/video/dansende-menigte-bij-concert-van-jebroer-in-duindorp.html Edit: The French rave has been terminated this morning. Really, this(!) morning, at 7am.
-
I hope so. I know of a 70+ couple that were very lax until just a few days ago. But now the whole family of the sister of one of them is infected. One daughter (the other is spared by pure luck), both husbands in law and both grandchildren. That sister and her husband (i.e. the grandpa and grandma) are waiting for the results of a COVID test. They had all celebrated christmas together. But it's exemplary that after they took the test, they went to the supermarket. Both. Together. *shakes head* But at least it awoke the aformentioned 70+ couple. They are more careful from now on.
-
You have arseholes all over the globe. Yesterday afternoon a Dutch rapper called Boef ("Crook") did a sneaky open-air gig. He mannaged to do it, because it was reported beforehand to the authorities as a protest against the lockdown. There were so many people that the police decided it was riskier to break it up than to let it continue. No social distancing at all. Last night, 2500 people from all over France and several foreigners gathered in an abandoned warehouse in Lieuron. Population: 784. Police force? Almost non-existing, obviously. The crowd was hostile against the few gendarmes that were there. At 5am they were still partying.
-
Old-Skool Pokey sound (4 channes 64kHz), and very nice instruments and composition! One suggestion, if the lead goes very high, it could be beneficial to reduce the 0,+1,0,-1 vibrato to just 0,+1 or 0,-1. Otherwise it startes "yelling" squeeling. And if the +octave percussive pre-note gets too high, you can also try a -octave percussive note. Oh, that's two suggestions
-
If I understand you correctly, you are moving around binaries? Or full installation directories of Altirra? You probably can't move just the binary.
-
Yes, I do. Perhaps @JAC! or WUDSN users can help you better. But I expect there's a path somewhere that points to the Altirra.exe binary.
-
Sorry, I should have been more specific. I assume you start Altirra from within Eclipse. Somewhere in the settings it should have a path to which Altirra binary it uses. Do you use WUDSN? I also assumed you know how to unzip a file to a specific directory. Phaeron (the author) has gone to great lengths to reimplement both the OS and BASIC, but they are not 100% the same as the original ROMs. But in your case, I doubt this has anything to do with it. It should work with a standard Altirra 3.90 install, and select 800XL, 64kB.
-
Perhaps you should download a fresh zip from http://www.virtualdub.org/altirra.html Unzip it in a newly created directory. Then point your development environment to that binary. Edit: and you need to setup the new Altirra instance with the right OS ROM files.
-
Huh? I haven't looked at the assembly code yet, but here it runs exactly the same on atari800 4.2.0, and Altirra 3.90. What do you mean by "it wont work"? What does it not do that you are expecting? Edit: the only thing I see "wrong" is that the upper and lower border "wiggle" by one scan line, which is probably due to you syncing to VCOUNT.
-
A 130XE version, where the graphics 8 data resides in an extended bank (ANTIC only), could be nice, too! You'll get an extra kilobyte free memory in BASIC if $9C00-$9FFF is not used anymore, and your main (CPU) memory has no screen data, so using graphics 8 is less of a problem. Flickerterm, ehm, flickers. Might be tollerable in a well-lit room on 60Hz in NTSC land, but on PAL I can't stand it. Similar to all the flicker modes that people erroneously call "interlaced".
-
Here's the "resulting sound" of using the fourth channel to influence the main melody similar to what is described here: https://atariage.com/forums/topic/258292-nothing-special/?do=findComment&comment=4699543 Applied to my first 3 channel 64kHz instruments version of Noisy Pillars (https://www.youtube.com/watch?v=7bQDMP2-iO0), it sounds like this: And the binary to run on real hardware or Altirra: noisy-pillars-t1-ivo-edit-fourth-channel.xex If you run this on Altirra and you mute the fourth channel (CTRL-ALT-4), it sounds 99% the same as the previous three channel version. By muting and unmuting channel four, you can hear what it adds. Edit: And during the high note passages, channel 4 does the opposite. It plays an octave lower, and at at least half the volume. Toggle CTRL-ALT-4
-
Perhaps you can also try using narrow playfield (see $D400/DMACTL). It also saves on Antic DMA cycles.
-
The page you referred to shows six unstable undefined opcodes, your list only five. You missed 0x9b SHS Q,Y Edit: oh, I misread. You listed only the ones that kickc uses. Sorry 😊
-
No, it's not. He runs his code on a 65C816 in 65C02 mode, which does not have these undefined opcodes. 65C02 (CMOS) != 6502C Sally (NMOS)
-
Here's the problem. The mads assembler doesn't know what the value will be in the Atari memory location that the label refers to when the code is actually running. For a human, after doing mva #bla blerk, it's obvious that blerk contains the value bla when exectuted on the CPU, but the assembler doesn't know that. So during compile time, a comparison with the contents of memory location blerk at runtime is impossible! Unless the assembler does extensive code flow analysis and has a notion of what each instruction does, it does not know the contents of memory locations during runtime. The assembler used by @JesperGravgaard's KickC might optimize this code construction if it is expressed as runtime code like @zbyti did with his K65 code. If I am not mistaken, his assembler does some of these optimizations. And blerk could be a volatile/hardware memory location That would be another cook. Or a biscuit.
-
I suppose this is what is requested: L3 = $05A2 ; value(s) might change in the future SOME_VALUE1 = 2 SOME_VALUE2 = 5 ;....code etc.... mva #SOME_VALUE1 L3 ;...... a lot of more code ...... ; compile time dependency ; if SOME_VALUE1 is changed to 0, the below code will ; not be assembled in the resulting binary #if .byte SOME_VALUE1 > #0 mva #SOME_VALUE2 L3 #end
-
Uhm, that's at runtime. #if is at compile/assemble time.
