Microchess

[Microchess]

And KimXXL might get you in trouble home 😀

[Microchess]

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

[Microchess]

8 minutes ago, phaeron said:

will bypass a fast E:/S: handler

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  

[Microchess]

1 hour ago, kenjennings said:

Is (was) the table guaranteed to stay there?

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.

 

[Microchess]

@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

 

 

 

 

[PoP Slicer sound, should we update it ?]

3 hours ago, emkay said:

two metallic blades hitting each other

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

[Plot and Flickering in Action!]

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

[Plot and Flickering in Action!]

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)

[Plot and Flickering in Action!]

6 minutes ago, Preppie said:

putting the pause before the plotship

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.

[Favorite keyboard-only Atari 8-bit games]

Certainly Thrust

 

or something like Everest Explorer?

 

And if you are a real sadist then try The Last V8!

[Rob Hubbard on the Atari 8-bit]

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

[First cc65 attempt, a utility...]

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

 

[XE ram simm mod help]

perhaps here? 

 

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

[Timeslip 2020 (48KB)]

3 hours ago, Nojeee said:

Happy days

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 😜

[Timeslip 2020 (48KB)]

@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?

[Unicorns season: Prince of Persia for the A8!]

I prefer 5 (what happened to #2 )

[Altirra 3.20 released]

9 minutes ago, antrykot said:

A couple of examples

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.

[Open a Screen cc65]

3 minutes ago, Irgendwer said:

cl65 V2.18

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?

[Open a Screen cc65]

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

[Open a Screen cc65]

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.

[Timeslip 2020 (48KB)]

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

[Unicorns season: Prince of Persia for the A8!]

You had to go there José  

Can't you see its merely some clever shadowing timed with the flickering of the light  

[Timeslip 2020 (48KB)]

25 minutes ago, Nojeee said:

To be honest, I didn't want to play around with that only to break something else.

 

 

[ST-NICCC 2000 "demake" from ST to Atari 8bit]

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?

 

 

[Whatever happened to Elite for Atari 8bit conversion project?]

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