Dr Do

One makes an appearance approx 30 mins into this YouTube video, but I've no idea where you'd find a hard copy of it (unless it's one of those already linked to in the previous posts!)

So in answer to the title of this thread: yes. (Either that or Rajni16 is still trying to work out ChatGPT).

Oh yes I spotted that on the title screen, but I meant the loading screen that appears partway through the bootup (Or at least it does on the cassette version I had).

Tenuous link alert: I recently discovered that part of the musical medley on the loading screen to Leaper is Bach's "Jesu, Joy of Man's Desiring". (Curiously, this melody is also used as the theme tune to MIT's lecture series on The Structure and Interpretation of Computer Programs. I assume this was mere coincidence...or was it?)

Well, how embarrassing; I was actually using a metal screwdriver. Fortunately my machine appears to have survived that abuse. To add to the curiosity: I thought I'd have a go with an older TV that I found in the loft, and lo and behold the colour comes up fine using the RF connection. Perhaps it does a better job of picking up whatever signal my machine is still able to put out? Either way the problem's solved for now, but I'll check out some of these alternative ways of getting video output. Thanks all!

Thanks - that helps me narrow down what to do next. I have a monitor to SCART lead but the TV I'm using won't take the signal at all (and I note from @Mazzspeed's comment that a mod might be needed for that anyway), so I will have a look at some alternative options. That makes sense that a crash would cause the display to go haywire like that, but I'm now curious as to (i) why this would occur as a result of adjusting the colour trimmer; (ii) why it would happen when there was no program running (unless there's always something running in the background when the machine is at the READY prompt)?

It's RF. My 65XE's display is in colour when used in place of the XL.

My PAL 800XL is producing black and white video output, with colour occasionally coming in but only for a second or two each time. I tried to adjust the color setting using the access point at the bottom of the unit. However, this just results in garbage appearing on the screen (as shown in these screenshots). Turning the machine off and on restores the proper display, but still in monochrome. Any ideas how to fix this, please?

So, I was searching the forum for advice on fixing my 65XE's keyboard and somehow ended up being directed to this thread. Half an hour later, I now realise I'm not going to get the answer to that question here...

Me too. I had no idea there was an Atari version either!

I suppose that's an object lesson in why error trapping matters...

Thanks for explaining that. I got an adaptor for my previous car (brand new in 2001 but fitted with a cassette player) but left it in my car when I part-exed it, probably in the hope that it would increase the value. Maybe I should get another one now...

I'd never heard of TapDancer or CAS2Audio until chancing on this thread and am now intrigued about how these two work. I presume that you need some connection between your Android and the target machine - or do you?

Now why didn't I think of that? Thanks vitoco, problem solved.

** EDIT: Problem described below now solved ** Sorry if this is the wrong place to post newbie questions like the one that follows. I've been trying to learn 6502 assembly, but it hasn't taken me long to get stuck. I was trying one of the examples from "Machine Language for Beginners", which was supposed to put ten "A"s on the screen. I soon realised that the code in the book needed tweaking to work, and so after a bit of trial and error came up with this... *=20000 ldy #10 loop lda #33 sta (88),Y dey cpy #0 bne loop brk (Excuse the tab spacing, it was lined up properly in the code edit window!) If I compile this in ATasm and then attempt to run the object code in the Atari800Win emulator using DOS Option L, it will display 10 "A"s as intended but then crash straight away. Changing the compile address from $4E20 (for example to $0600) or changing the last instruction to "brk" (or removing it completely) leads to the emulated machine crashing as soon as the object code is started. But switching to WUDSN (with the opening statement changed to "org" for the MADS compiler) makes the code behave differently; there, it causes nothing to happen except the debugger opening with a message about an "illegal operation". Sometimes, if I run it and then start Altirra separately then it will behave the same way as Atari800Win did. Changing "brk" to "rts" though will cause WUDSN to open up Altirra automatically, which will then display the As but immediately reboot into BASIC - which makes sense...I think? All this is leaving me scratching my head, but I'm guessing there's a simple solution. Any suggestions please?