Obscure 6502 question

Given the history, I suspect somebody here may remember enough to answer…

[dunno why I’m playing with this old code, I think I’m putting off going into the kitchen to brew pasta – it’s cold in there!]

I’m fiddling with some code (written by Acorn) and my emulator is hitting an overflow error. There is quite likely to be a bug in my 6052 core, however it does raise an interesting question.

The failing instruction is using post-indexed indirect addressing. The 16 bit value giving the base address is being read as &FF, &FF. The Y register giving the offset is &1B (27). The emulator core’s memory lookup is choking on the effective address which is 65562.

So while the problem is likely somewhere else I would like to ask – if you use indirect addressing adding a value to &FFFF, what is supposed to happen? Does it wrap around in the page (&FFxx)? Does it wrap around to zero (&00xx)?

Thanks.

I’m pretty sure it is supposed to wrap around to zero. I don’t think it’s supposed to affect the carry flag. But it is a very long time since I worked in 6502 assembler!

Rik – Going back to 1982 !!
I seem to remember that an obscure fault in the 6502 chip itself meant that you could not make a jump from the memory page you were on but just wrapped around to the start of that page. Something like that anyway.
Several people came unstuck, as it was not generally known at the time. I seem to think that a workaround was published (by Acorn ?) during that year.
There must have been an acceptable solution as I don’t remember it being commented on later and several coding groups produced some clever and impressive demos later.

Rik – Going back to 1982

when you were 8!

I remember a wonderful article in BYTE magazine from about that time about the design of the 6809 which was intended in some sense to be a 6502 done properly. The author claimed that the 6809 was the first 8-bit chip actually to be designed from the programmer’s point of view rather than cobbled together to satisfy the physical constraints of the time.

The 6809 is the most beautiful of the 8 bit chips, by a very long way.

The bug is in the JMP instruction, not the post-indexed addressing, and only on early versions: http://gunkies.org/wiki/MOS_Technology_6502

The 6809 is the most beautiful of the 8 bit chips,

I am glad Dave used the word beautiful. I agree. I have always felt that the aesthetic side of computing was vitally important, and that marketroids are missing a trick if they pay no attention to it. Did some troublemaker in the back there mention Intel?

I loved the original ARM instruction set – and the addition of the MUL and MLA instructions. Beautiful is exactly the right description.

For all I spent nine years documenting them, I’m not so enamoured of all the later complications – oh, they work and they’re damn useful, but they’re not beautiful any more.

I am glad Dave used the word beautiful.

I’m one of the people who sees the beauty in mathematics; I think you share that feeling too.

Snap!

the 6809 which was intended in some sense to be a 6502 done properly

It’s interesting to learn a little more about this. It was apparently used (as an optional alternative) within Acorn’s System 2, as well as for the Dragon 32, TRS-80 and Thomson MO5!

The 6809 was used in the TRS-80 Color Computer, nicknamed CoCo.

I spent many happy hours programming for the 6809 under Flex9, but I didn’t have any of the commercial computers: I wired my own on a double extended Eurocard with mini-wrap wire soldered to IC sockets. I still have it; I have too much of an emotional attachment to it to throw it away.

Twin Teac FD55-GFV2 floppy drives.

LDMFD R13!, {Rx-Ry, PC}^

Best.
Instruction.
Ever.
(^_^)

It’s not bad, is it! 8~)

LDMFD R13!, {Rx-Ry, PC}^
Best.
Instruction.
Ever.
(^_^)

Ain’t that one of the “my 32 bit system says I think that’s Dingos kidneys after 6 hours in the sun”.

Only if R13 is in the register list – otherwise it’s fine (and of course extremely useful). It was never any use with R13 in the list – the resulting contents of R13 were unpredictable.
That’s true for any base register – don’t have the base register (R13 in this case) in the list with writeback (!). Legal but useless (unpredictable) in early architectures, illegal from ARMv7 onwards.
“ARM deprecates using these instructions with both the LR and the PC in the list.
The SP can be in the list. However, ARM deprecates using these instructions with SP in the list.”
(I wrote those words…but had to go and look them up just now… 8~)

For an 8-bit CPU, the ATmega instruction set is quite nice to use, if a bit confusing at times: http://www.atmel.com/Images/doc0856.pdf

Incidentally, the unpredictability of LDMFD Rx!, {Ra,…Rb,Rx}[^] is not in any sense a bug: it’s just logic. You’re specifying two contradictory operations: load Rx from memory, but also take the old value of Rx, increment it by 4n (where n is the number of registers in the list), and put the result in Rx. Um, okay, which do you want me to do?

Um, okay, which do you want me to do?

Take Rx, load all the registers, update Rx afterwards.

The complication arose from the fact that this is a simple RISC processor so doesn’t include logic to cater for dumb operations.

Yes, but what you want to update Rx to? With the register list you’ve asked for it to be updated from memory, and with the ! you’ve asked for it to be updated to the value it had before the operation, plus 4 x the number of registers in the list. It’s not just a dumb operation, it’s a self-contradictory operation. Two logically mutually exclusive requests in a single instruction.
If you want the final value of Rx to be simply the old value plus 4 x number of registers in list, then why is Rx in the list? If you want it to be updated from memory, then the ! is just a mistake.

Yes, but what you want to update Rx to?

Yes but no but yes but no but yes but…

That’s exactly why it isn’t a bug, and probably why it took until ARMv7 for it to be “officially” deprecated¹. As you say, we’re asking for one register to be set to two different things at the same time.
Duh.

¹ Us old timers are smart enough to figure this out, we don’t need our hands held by mommy.²

² Cue thread pointing out o != u. :-)

“That’s exactly why it isn’t a bug” – precisely – as I said way back!

Just so you know, I’m the old timer (retired 2007) who wrote the instruction architecture section of the ARM Architecture Reference Manual (all editions from 2000-2007). And the ARM Assembler Guide. Yes, you can blame me for the errors…and David Seal, who checked the ARM ARM…

who wrote the instruction architecture section of the ARM Architecture Reference Manual

It’s a nice piece of work, that.

I have a thin ARM ARM and a much fatter ARM ARM.
Kinda wish they’d make a Cortex era one in a print version. PDFs just aren’t the same.

Thanks! 8~)
Actually, I see that my final piece of work was actually issued a few months after I left – in April 2008, the VFP instruction section. Other people were still working on the Debug section when I left…
I think the last one actually printed was Issue E (June 2000) of the 2nd Edition, covering up to v5TE. It’s certainly the last one I’ve got (well thumbed…) and I think I’d have had any later ones.
I have to admit to using the PDFs even of things I’ve got printed copies of – on a portrait 1050×1680 monitor on a PC alongside my Pi 1600×1200 monitor.