ggn

Thread cleaned up. Thank you for your interest in Barbarian!

Return of the fart!

First of all, rln's only job is to combine object files together and perform any fixups needed. From what I remember it contains 0 jaguar specific code apart from the output formats (but then again COFF is a fairly common format). As for your question, my guess would be that writing anything between the 2 and 8 megabyte space is simply ignored. You won't get a bus error or anything, so you can knock yourself out writing or reading to that address space but you'll either get garbage or some fixed pattern (zero I'd say). A way to check would be something like cj suggests, set up an object that is displayed per frame in ram and start filling addresses $200000+object's data address. So if you object's graphics data start at $6000, go for $206000.

That's better than 0% of Atari ST machines being able to play it (as it's not out yet)

You'd need something like a KryoFlux or something similar. STX files cannot be written using an ordinary floppy controller.

Just go and edit the "*.MS?" to "*.ST" and hit refresh on the file selector (the widgets above the file list should do the trick). Then you should be able to select .st images.

Here's a nice resource with hands-on examples: https://www.omnicalculator.com/math/modulo Sure, it's pretty good!

And Atari800Win PLus 4

There are lots of things you can do (and many different ways to do these things). Reading your code I noticed that you call random and check if the value returned is within range. This is super slow as you're calling an expensive routine over and over and is probably the worst offender for speed in your program. So, how to speed this up? From your code I see that the number has to be between $c1 and $dd inclusive. Unless I'm mistaken that's 29 numbers. So, instead of waiting until the random number generator gives you the right number, why not modulo the result instead? Quick math refresher, the modulo is the result of a division. So if we divide by 29, the modulo is guaranteed to be between 0 and 29. So, something like this will do: loop: move.w #17,(sp) ;get random trap #14 ;call GEM and.l #$ffff,d0 ;clear the upper 16 bits so that division will not overflow divu #29,d0 ;divide by 29. The low word of d0 now contains the result of the division and the high word contains the modulo swap d0 ;bring the modulo to d0.w. This will be between 0 and 29 add.b #$c1,d0 ;now our number is between $c1 and $dd move d0,-(sp) ;put random on stack move.w #2,-(sp) ;print it trap #1 ; jmp loop That should be fine. Of course that's far from the most optimal code but I'm sure it's much faster than your version Regarding the stack: Physically it occupies a part of your RAM, so it's not at some magic place where it doesn't matter. To elaborate this using a cruel graph: ooo..........................................Xxxxxxxx.. ^ ^ RAM START RAM END This is a very rough model of the ST RAM layout. The 'o's at the start is memory reserved for the system. The '.'s is free memory that applications can use. The 'X' is the address of the stack, and finally 'x' is screen RAM. So, computers usually place the stack at the highest allowed address, since they go backwards. I.e. when you push parameters on the stack you use -(sp). This works exactly like an address register (and in fact SP is register A7 in 680x0). So what happens if you don't tidy up the stack? It starts writing RAM backwards. So something like this will happen: ooo................................XXXXXXXXXXXxxxxxxx.. ^ ^ RAM START RAM END The stack will start writing over RAM. Usually your program starts in low RAM, right after the 'o's, so it will be safe for a while. Perhaps even forever if you don't use the stack too often. But if you keep hammering data to the stack it will eventually go and overwrite everything, including your code. This will definitely lead to a crash! Hopefully this explains things.

Fixed

Off topic posts moved here, please stop re-posting them here.

Post which ones are failing for you and I'll have a look. (not raycaster obviously, this should work with latest head).

Pull latest revision, this has been fixed. (Way past the point of asking people politely not to PM me about rb+ things anymore, I'm just going to post their messages here in the forum from now on)

Of course, if the label's address is static you can simply align it during build. For example (rmac):

Remove -flto and try again.

Well done Poison and crew! As for the apologies, the demo is out so it's all good in my books . No need to feel bad that it took longer than expected to be released! Also, I hope you will reconsider and do more stuff for the Atari 800 in the future.

Hi, not sure if you ever got this to work, so here's a version that seems ok: clr.l -(SP) move.w #$20,-(SP) trap #1 ;supervisor on addq.l #6,SP clr.b $FFFF8260.w ;set st low resolution move.w #2,-(SP) trap #14 addq.l #2,SP movea.l D0,A0 move.w #32000/2-1,D0 fill_loop: move.w D0,(A0)+ dbra D0,fill_loop scroll: move.w #2,-(SP) ;get screen address trap #14 ;0 1 2 3, 4 5 6 7, ... , 16 17 18 19 ; ;0 2 4 6, 8 10 12 14, ... , 32 34 36 38 addq.l #2,SP ;0 8 16 24,32 40 48 56, ... , 128 136 144 152 move.l D0,scrolladr addi.l #16000,scrolladr ;point to the middle of the screen addi.l #152,scrolladr ;add to get to last word, first bit plane move.l #256,D7 scroll_loop: movea.l scrolladr,A6 move.w #37,-(SP) ;wait for vbl trap #14 addq.l #2,SP move.l #15,D4 ;set rows to shift bploop_resd5: move.l #3,D5 ;set bitplanes to shift bploop_resd6: move.l #18,D6 ;set words width for each row (one bit plane at the time) lsr.w (A6) subq.l #8,A6 bploop: roxl.w (A6) bp_no_carry: subq.l #8,A6 dbra D6,bploop adda.l #160,A6 ;jump to start. (at the end) addq.l #2,A6 ;inc to next bitplane dbra D5,bploop_resd6 adda.l #152,A6 dbra D4,bploop_resd5 cmpi.b #57,$FFFFFC02.w ;space pressed? bne.s scroll_loop ; dbra D7,scroll_loop clr.w -(SP) trap #1 scrolladr: DS.L 1 END In addition to making the scroll to work I modified a few things like adding a random pattern to the screen, and scrolling the middle part of the screen so it doesn't show tearing (too much that is), and waiting for space to exit.

Threading using the trace flag sounds a bit odd but I'd be interested to see the results! In any case let me suggest a couple of ideas: a) You can use interrupts to simulate threading. There are quite a few of them on the 68000 but the useful ones for your case are the ones that are tied to timers, of which the ST has 4 (A, B, C, D). By programming the clocks you can do timeslicing easily. A fifth timer you can use is the Vertical Blank interrupt which occurs 50 or 60 times per second (depending on your monitor refresh rate). During those interrupts you can save the CPU state, run your code and then restore it back. Then the other "threads" won't even know anything happened (unless you might want to for some reason) b) If you require more than the 4 (or 5) timed interrupts then you could program a timer to run an interrupt that "simply" switches to the next thread's cpu state and then exit. That way you can have an arbitrary amount of threads that again will run in a time sliced manner. Hope this gives you some food for thought! P.S. Before anyone mentions it - yes there are some other timed interrupts one can employ such as the HBL interrupt but I didn't want to bog the answer down with a complete reply.

I've been also taking some peeks at the source, first instruction is "jsr XXXX" where XXXX=$900. So my guess was that $900 contains something about protection. A quick search revealed two snippets of code within COPYPROT that assembles to $900, which allegedly goes to sector 717 and $b0. The first one contains a bunch of hex strings while the other contains some code. So it seems there's a bit more work involved until we understand what's happening!

Are the full wav files for invitation to programming 3 available somewhere? As far as I can understand the attachments above only cover the spoken parts, not the programs themselves.

Tell me about it

You probably don't even need to do that - just go to gcc top directory and type Then configuring and building gcc should also build those libraries.

Hi, First of all, thanks a lot to Bob Polin and Kevin Savetz for providing the source code! That said, anyone managed to run this yet? So far I managed to load the "asm" file into synasm, then mount the two disks so that it can find the files, then typed "asm" at the prompt. That gave me 4 files, "max.1", "max.2", "max.3" and "max.4". From what I understand so far, files 2 to 4 are simply data files (graphics by the looks of it). I made some experiments with dos 2.0s that source code disk 1 comes with. Running "max.1" from dos freezes the machine. "max.2" to "max.4" seem to load and not run anything, so I tried loading them before "max.1" but I still get a freeze. Altirra debugger says it's stopping at a KIL instruction at 102c. Ideas, anyone?

No worries, everyone has to start somewhere! Let me stop you there for a second for a small clarification: There are two kinds of shifts on the 68000 - arithmetic and logical. Arithmetic (asl/asr) keeps the leftmost bit intact as it shifts, while logical doesn't. Arithmetic shifts are great for when you want to do things with integers (as by convention the leftmost bit is considered sign) but since your data is not numeric, using asl is going to cause weird artifacts. Well, the 2nd run looks like you're not adjusting your offsets properly - probably your "add.l #152,a6 ;jump to start. (at the end)" needs to be 160? Also, I see you're using devpac 3, so why not take advantage of the debugger? IIRC you can hit alt-d after you assemble, then you drop to Mon with the program loaded, then you type 'r' and 'g' (for 'run' and 'go'), wait for it to crash and then you should have a better idea of what's happening.

The X bit is deliberately not touched by many instructions so you can perform stuff like that roxl loop. As for your main question, I tried modifying the program to use roxl everywhere and as expected, it shows up some junk on screen (a weird wrap around effect). This is due to the X bit not being clear when you first enter the loop. How to fix this? One way of course would be to do something like clearing the CCR (move #0,CCR) but we can do something more elegant. Instead of roxl'ing the rightmost word you can lsl it. This has the added bonus of ignoring the state of the X bit initially and then setting it if the leftmost bit is 1. So in essence this will reset the X bit . So your loop becomes: bploop_resd6 move.l #18,d6 ;set words width for each row (one bit plane at the time) lsl.w (a6) subq.l #8,a6 bploop roxl.w (a6) bp_no_carry subq.l #8,a6 dbf d6,bploop (untested at the moment but I hope you get the gist). Now, when you get this working you'll see an odd tearing of the screen. This is normal and happens because you update the same buffer as the one the shifter chip shows on screen. If you do something like "add.l #16000,scrolladr" before you enter your loops, i.e. have it scroll the middle part of the screen, the tearing will go away. Of course to get rid of this problem properly you'll have to use double buffering. But hey, one step at a time! Finally, a couple of optimising hints: a) If you can afford it (memory wise) don't use dbra, especially in inner and tighter loops. Instead, prefer to unroll the code: bploop rept 19 roxl.w (a6) subq.l #8,a6 endr b) While we're at it, it's a bit wasteful to keep reducing the pointer when you can use the wonderful addressing modes of the 68000: i set 144 bploop rept 19 roxl.w i(a6) i set i-8 endr This will generate 19 instructions that have the offset hardcoded and decreasing (i.e. roxl.w 144(a6), roxl.w 136(a6), etc). Hope this helps!