Wrathchild

And KimXXL might get you in trouble home 😀

Using a hex editor I've added a pre-section to setup the jumps (S: PUT was also being used) and then replaced the JSR/JMP calls with the new vector. Seems to be OK. MiniChess.xex

Indeed, and as the OP's intent (by jumping direct into the O/S) appeared to be to use the OS's routines, choosing to go with obtaining from the OS device table. Whether that would still place nice with other handlers present is an exercise for others

I had included an image of that area in my original post but removed it (hence the edit). I'd considered that as maybe less sure if any other startup code running before and closing or opening things would maybe alter the $34x location. Additionally, xxl is using the S: GET routine without that having been opened and hence not present in that area to perform the same obtaining of the address, hence my decision not to opt for this. From the OS listings I'd consider that table fixed and others (e.g. Altirra OS, MyIDE) would have followed this and not relocated it, but there maybe others that don't.

@xxlNo real excuse for jumping directly into the OS these days? The $F2B0 routine in the XL OS is reflected in the Vector table at $E400 (so the E: PUT is at $E406), but stored as EOUTCH-1. Similarly SGETCH-1 is found at $E414. So during initialisation this can be inserted (incremented) into a replacement JMP which is called instead. E.g. InitOutCh: CLC LDA $E406 ADC #1 STA VecOutCh+1 LDA $E407 ADC #0 STA VecOutCh+2 RTS VecOutCh: JMP $FFFF Then this should allow your programs to work OK on other OS's. E.g. for OS/B

that would be a bad design, the blades of a pair of scissors slide closely past each other

Sorry Preppie, how was I blind to that Indeed, there only needs to be the plotShip and not the eraseShip function and just call plotShip with color zero to erase

No he's not, the loop draws at xpos of I and then waits and then erases at I and then I is incremented, then repeat. The pause is in-between the draw and erase and so only one ship is view, he just considered about a trail (which would occur if you incremented I before the erase and then draw at the same I) As others have already covered, the slowness of the plot function is more than likely causing either screen tearing or flicking (e.g. if the time to erase & draw is exceeding 1 frame)

That doesn't make sense as the ship is then erased for the greater proportion of time, there would be little sense in drawing it.

Certainly Thrust or something like Everest Explorer? And if you are a real sadist then try The Last V8!

Bit confusing to add a David Whittaker tune to a Rob Hubbard thread?

You will be fine adding the option '-O' (capital o) to your cl65 command to enable the optimizer. As an exercise for you, compile the C to assembler without optimizing, copy the '.s' generated aside, then repeat with '-O' and compare the two, e.g. cl65 -t atari -S -Wl "-D__RESERVED_MEMORY__=1" --static-locals autodata.c ren autodata.s autodata1.s cl65 -t atari -S -O -Wl "-D__RESERVED_MEMORY__=1" --static-locals autodata.c ren autodata.s autodata2.s [Edit] Thinking about it, you can just use the -o (output) in the command line: cl65 -t atari -S -Wl "-D__RESERVED_MEMORY__=1" --static-locals -o autodata1.s autodata.c cl65 -t atari -S -O -Wl "-D__RESERVED_MEMORY__=1" --static-locals -o autodata2.s autodata.c

perhaps here? @Mathy mentions one here but the link to the article no longer works?

Thanks for those memories, I did something not to dissimilar. Whilst at Uni I had a 1040STE and the MadMac assembler and could send code from the ST's printer port to my 800XL's joystick ports. Between the Atari and C64 was not as neat though as I used a single cable to transfer nibbles but had to hand type the 64 side into a Replay cartridge's monitor in hex 😜

@Nojeee how were these written at the time? Was code assembled natively or cross-developed and transferred? Did you have disk drive(s) or had to use tape units?

I prefer 5 (what happened to #2 )

Please excuse a nag, but I would recommend using 'xex' as the extension for any binaries you produce as 'com' has long since been less used due to a main proportion of people downloading to a PC where that extension has its own association.

I have cl65 V2.17 - Git 5c8854f I'm not sure what the behaviour, say with gcc is, but I think the use of -D is just to pass to the pre-processor? If you've edited the atari.cfg to non-zero then because the define isn't passed to the linker then it would use that and so work in your case?

@TGB1718 & @Irgendwer I've spotted the problem... you can leave the cfg/atari.cfg as it was: __RESERVED_MEMORY__: type = weak, value = $0000; But instead of passing the define to cl65 this needs to be passed onto the linker instead with: -Wl "-D__RESERVED_MEMORY__=1"

Irgendwer didn't use --static-locals but I presume you tried without too (plus with a space after the -C)? Can you build with an extra option: -Ln autodata.lbl Then post the xex and label file so we can debug.

Looks like you have BASIC enabled as the binary uses that area EXE: Loading program 0006-0007 to 02E0-02E1 EXE: Loading program 000C-7B64 to 4000-BB58 EXE: Launching at 4000 (Not often we see the Run address loaded before the code but just as legitimate) Timeslip_2020 (Basic Disable).xex

You had to go there José Can't you see its merely some clever shadowing timed with the flickering of the light

Well, at Revision 2020 the Bitshifters has release a BBC Micro version running natively, so any takers for doing a version without the VBXE or UNO on the A8?

With the Uno cart's help we could have a filled vector version