ggn

Makes me want to have it running on my 800XL 24/7, preferably connected to a huge monitor. Great composition.

http://rmac.is-slick.com/ is actually the home page for both rmac and rln. If you want to take a look at the issue yourself, you'we more than welcome! You can also open a bug report at the rln bug tracker, if you have a repro case we could also have a look at it too.

10 years old project, whew! I literally had to dust off the cowebs from the source :). In any case, patch applied and binary rebuilt: cden_skunk_1.1.zip @CyranoJ is the server meister these days so I'm sure it'll appear in Reboot's site soon. (Since this thread started with a whimsical story, allow me to contribute one: I have never owned a JagCD and probably never will. So how did I ever manage to make this thing? Well, @sh3-rg was the only one of has who owned a JagCD at that point, and we were looking into producing our own CD run of a title, doesn't matter which really. The first CD run we made was made with the aid of Jagware (I think @Fredifredo encrypted it for us but memory is very hazy. Thanks to whoever did it!). We really weren't keen on finding old machines with parallel ports and making a custom cable just for the sake of encrypting a damn CD! Especially not when we had those shiny new skunkboards that were supposed to transfer data to and from the machine! So I took a look at the source code Matthias Domin had on his site and took a wild stab at adding skunklib and initiating a transfer using skunk functions. I sent that to @sh3-rg and of course it didn't work! This triggered a pretty wild session of me debugging using colours I stuck into the BG register, and @sh3-rg then trying the binary and telling me what colour he would see when the program froze. I can't stress how confusing this was because a) @sh3-rg is colour blind so haha nice try I used some weird colour, b) I was assuming that the colour format for BG was something else than it actually was (something like RGB16 vs CRY? Really can't remember) so the colours I would get back looked nothing like the ones I assumed I was setting! In the end someone suggested ROMWIDTH was the issue (either @sh3-rg, @SCPCD or @Zerosquare. Maybe perhaps someone else? Sorry, it's been so long!). Bloody ROMWIDTH, it's always that thing when things go South. Anyway, saving and restoring it before the skunkboard transfer magically made things work! Of course we hit another snag, the transfer would freeze for some unknown reason. I guesstimated that it might be the transfer chunk size so I set that to a very low value and it worked. We could have tried increasing the chunk size so it would transfer the key faster but in the end we shrugged it off, closed all the source code and command line tabs, and went and did other things... So there you go, just an amusing story for interviews I guess(or something to tell to young know-it-alls who think they know stuff!): I once debugged a piece of code 3000km away from the actual machine by changing the palette registers)

1) Really? What's your use case? I just tried this without issues: ROM,rom_bmp_player1,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player2,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player3,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player4,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player5,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player6,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player7,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player8,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player9,gfx_clut,assets\partipal.bmp ROM,rom_bmp_player10,gfx_clut,assets\partipal.bmp ROM,sfx_11,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_12,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_13,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_14,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_15,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_16,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_17,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_18,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_19,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_1a,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_1b,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_1c,sfx_mlaw,assets\SFX\touche3ATARI.wav ROM,sfx_1d,sfx_mlaw,assets\SFX\touche3ATARI.wav 2) No limits. Pack to your heart's content

First of all, sorry for the misinformation on where to apply the romwidth code, I'm forgetting things... Anyway, seems like you are out of bus time as @SCPCD proved above. The obvious solution to this would be to keep as much as possible in RAM, but that's not always doable. On the flip side: do you actually need all the data you have in RAM at any given time? I'd be willing to bet "no", since each level will more or less have different backgrounds and musics etc. The code certainly won't be that big, I would assume that, including raptor and zero's audio library, it shouldn't go over than 100-150k. Then we also add 16k from the start of the RAM which is reserved for various things and that's it. Let's round up and say you have about 1.8Mb to play with. That's still a lot of space to store stuff. Now, something that is swept under the carpet with rb+ to avoid confusing people much is that assets.txt makes it easy for assets to be loaded and positioned in RAM and ROM. But that doesn't mean that they have to stay in those areas in order to be displayed (or played)! For example, everything can be kept in ROM and the relevant data for each level can be copied ad hoc before the level starts and used there. This of course creates an extra burden to the programmer as they have to do their own memory management, so training wheels are off! But it is possible to modify raptor lists with graphics base addresses and same thing for the audio assets. If one is feeling bold, rb+ even supports unpacking data from ROM to RAM - have a look at project pack to see how you can do this. Otherwise a straight "memcpy" from ROM to RAM will do the trick as long as you know where you copy the data from and to, and what size they are. As an example, you can DIM an array and then use strptr to determine its address in RAM. (Again, project pack shows how to do this). If you know that your background pic is 24k, then "DIM back[24*1024] as BYTE" should do the trick. Also, if all your background pics are the same dimension, they're all going to be exactly the same size, so you can re-use the same buffer over and over. Same thing for game sprites and audio. One final thing that comes to mind (again something that assets.txt performs in a hand-wavy manner): you have to make sure that your buffers are aligned to 8 or 16 byte boundary (I forget what types of data need 8 bytes and 16, so I usually just align to 16)! The easiest way to do this is if you assign memory locations by hand (for example, your background buffer will live at $10000 - there we go, a nice aligned number. Of course you have to be absolutely sure nobody else uses this chunk of RAM....). The second easiest way is to allocate the amount of RAM you want plus some extra, then take that address and align it by hand. So something like: dim background_buffer[16*1024+16] as BYTE dim background_address as long background_address=(((long)strptr(background_buffer))+15)&0xfffffff0) If it reminds a bit of the way we align sample buffers for Zerosquare's player, it's the same principle. So that's it for now, I'm not sure you want to undertake such a complex task but worst case it might help some people in the future that encounter the same problem(s). Good luck in any case, and do ask if something is unclear. [EDIT] Another possibility is of course to have some dummy entries assets.txt that point to RAM and supply blank files of the same sizes you need. Then all the alignment issues are solved for you and you just need to copy (or unpack) your desired data on top of the blank ones

A line in assets.txt like ROM,BMP_FRAMEA,gfx_clut16,ASSETS\hallframeA.bmp actually tells the program that puts all code and graphics/sounds/etc to place the .bmp somewhere in rom, align it to 16 byte boundary, convert it to jaguar native format, and expose a variable called BMP_FRAMEA to the program that contains the address in the ROM. As for bandwidth concerns, it's exactly what @SCPCD described - it'll probably be fine unless you overload the OP. In the later case magical stuff will happen. There are things to do to get over this, but let's cross that bridge when and if we come across it.

Okay, you might be getting bit by ROMwidth issues since it works ok in VirtualJaguar. We discussed this topic here: There are 2 snippets of code in that thread. IIRC what I have in the first post should work fine on the skunkboard. Zerosquare's is more generic but it hasn't been verified by anyone on skunks. So I would suggest you put he snippet from the first post in your rapapp.s, probably after the "YOUR APPLICATION GOES HERE" comment. If that works, try swapping it out with Zerosquare's. If that works then cool, I'll add it as standard boilerplate code in all rb+ projects. (hey, it's only been 4 years since I asked for verification!) If neither work we'll figure out something else...

If the original owner cared about the files, he/she would have recovered them or ask someone to do it for them. So personally I'd just wipe everything. To me this is invading someone else's privacy, and to be honest I would be very unhappy if I found out that someone has personal documents of my own (or even put them online to add insult to injury!).

Really cool! After the 7 and 15 part 256 byte intros on MS-DOS it's great to see other platforms picking up the challenge of fitting more than one effect in a bytetro :).

Okay, makes sense! Please feel free to submit an issue and fixes in our [url=http://rmac.is-slick.com/contact/contact/]bug tracker[/url] so that everyone would benefit from your fixes :).

Good stuff, congrats to everyone involved! Just a quick note: I could not get the disk a side a to boot in Altirra as I had disk accurate timings and XF551 emulation. All other drives (1050, 810 etc) boot the disk fine, but XF551 seems to load about 3 sectors, then halting for quite some time, then loading 2 sectors (or so) every few seconds. This ends with a high pitch voice emitted and seemingly nothing else. I did note that the magazine uses XDOS 2.43N, is this a known defect maybe? (Very tempted to write the image on an actual floppy on my XF551 and test this out).

That actually says more about antivirus programs in general than Microsoft.

This is weird because there has never been v1.13.6: version went from 1.13.5 to 2.0.0 ;). But I reverted to roughly that point in the repository and built rmac - sure enough it is perceived as legit code. You are encouraged to update to the latest version here as we fixed this and added a bunch more fun stuff like the ability to assemble a binary without header at a fixed address (-fr)!

Just for the record, I find it really hard to believe rmac is assembling that code without errors given that here I get "Error: inappropriate addressing mode" when I try to assemble the snippets above. The only assembler I've seen assembling code even if it has errors is GNU AS (which is horrible!). One thing to check, are you sure you're not getting errors and using an older .o file produced by rmac?

I never used this so I don't have the sources for it. But here's some comments from the peanut gallery on this: It's from 2003 so God only knows if it'll work with today's tools. (although the report says it was working with gcc 4.x so it might be fine) The speed claims are rather dubious and they don't include any information on how they build the code (did they build gzip with -O0 for example? Then sure, I would guess that an optimiser would make this run faster!). Also, is this platform dependent or x86 only? All the clever size optimising stuff they mention like dead code elimination and auto inlining should be possible with modern gcc versions. Just enable link time optimisation and/or perform a unity build of your code. If you're aiming for really good performance (and let's face it, a 14MHz 68000 is not exactly a CPU you can code freely without consequences for a long time) you're probably much better off sticking to a compiler and learning what code it produces (Brownbot is your friend) so you can adjust your programming style to that instead of relying on an automated tool that was probably written for generic purpose optimisations without aiming for the best possible.

My weapon of choice since the early 90s: "Pacman" joystick manufactured close to where I live in Athens, Greece. For some reason very sought after by people who participate in Kick Off 2 tournaments. Tough as nails.

I'm doing fine thanks! Just dabbling with various bits and pieces here and there. I suppose that wiring up the XF551 to the greaseweasle won't be straightforward like plugging in a stock cable though, right?

I'm getting one soon but sadly no PC 5 1/4" floppy drive here, only a XF551. I'll see if I can source a drive, then I'd gladly do some tests for people.

Ok, so here's the situation: 1) It's the year 2020 2) Even myself had troubles running this thing 3) I know the principal DOSbox personally and I'm sure he won't mind 4) I don't give a crap about imagemagick's status 5) You people continue using this huge hack and you're all lovely With all these in mind, here's an archive with all tools inclusive, it's been tested on Windows 10 and it's fine (basically it should be the same as the latest official version but with all the things bundled). Hopefully this will work for everyone! Do let me know if you encounter problems with it though. quake_all_tools.zip

Hi, I'll have a look tomorrow, it's too late in the evening for anything that requires actual thought!

One please Panos

If you are preshifting, I assume you won't be using the results in real time. Why not just write a software preshifter and roxr.w the hell out of your buffers? You would have been done by now instead of fighting over blitter bugs

If you thought the hotels were bad, wait till you get a load of https://www.forbes.com/sites/insertcoin/2018/02/17/atari-is-launching-its-own-cryptocurrency-atari-token-because-of-course-it-is/

Sorry it took that long - sometimes things get too hectic! Anyway, the risc parser has been hardened against these kinds of instructions. A patch has been submitted and if Shamus agrees with what I did then it'd be added to the main tree soon . (You can of course download the patch file and try it out yourself if you compile rmac on your own!)

Paranoid's STE faq has you covered http://www.atari-wiki.com/index.php/Atari_STE_FAQ_compiled_by_The_Paranoid_/_Paradox