How are the memory values for unoccupied address ranges produced?

[stm]

Hi,

this is more a question out of curiosity: When I look in the machine monitor at addresses that are not occupied by memory or peripherals, the memory value always appears to be the high byte of the address, e.g. if I look at 0x9000, the value is 0x90, and if I look at 0xC000 when no floppy controller is present, I see 0xC0. The behavior is also identical when I do this experiment in the WinOSI emulator.

How are these values produced? There must be some logic on the board or in the CPU that does it.

Stephan

[bxdanny]

I often wondered about that too. There's nothing on the board that would do that, so I'm guessing it is within the CPU. Probably some kind of relatively low-resistance path connects the data bus lines with the corresponding lines of the upper half of the address bus, so that when nothing else is driving the data bus, those values will appear. Does that happen with CPUs other than the 6502? How about with the 65C02?

[RedskullDC]

Hi stm, et al.

Looking at the schematics for the 600D board, I can't see any active bus termination either up or down.

As bxdanny suggested, it is probably some parasitic effect within the 6502 causing the old Address bits to "hang around" while the data inputs are floating.

Cheers,
Leslie

[stm]

Interesting theory that it comes from the CPU internally. But that does not explain then why the behavior is the same in the WinOSI emulator, unless it has specifically implemented it.

[Mark]

I recall reading somewhere that it was an artifact of the internal bus of the 6502, the last data on the bus was the high order byte of the effective memory address. Unfortunately I can find no online reference for that belief. But yes, WinOSI emulates that behavior specifically because that is how my OSI operates as do other NMOS 6502 based home built computers I've built in the past. I'm not sure how 65C02 or other 6502 clones respond though. Perhaps the visual 6502 project or SIM 2600 could provide some insight?

[BillO]

I'll go with bxdanny on this. The high order byte is read last by the 6052 and it will hang around the bus on a system (like the OSI) that has a relative ton of capacitance knocking about unless it gets driven by something. Consider it loitering.

[Mark]

Well it's definitely the value read on the bus and not the effective address.

I just tried:

Code: Select all

0300 A2 FF    LDX #$FF
0302 BD FF DB LDA $DBFF,X
0305 85 00    STA $00
0307 4C 07 03 JMP $0307

And on real machine $00 shows DB, not DC . Looks like I need to correct WinOSI.

[Mark]

I tried this program:

Code: Select all

0300 A0 FF    LDY #$FF
0302 A9 DB    LDA #$DB
0304 A2 00    LDX #$00
0306 84 FE    STY $FE
0308 85 FF    STA $FF
030A 88       DEY
030B B1 FE    LDA ($FE),Y
030D 85 00    STA $00
030F A1 FE    LDA ($FE,X)
0311 CA       DEX
0312 85 01    STA $01
0314 B9 FF DB LDA $DBFF,Y
0317 85 02    STA $02
0319 BD FF DB LDA $DBFF,X
031C 85 03    STA $03
031E BE FF DB LDX $DBFF,Y
0321 86 04    STX $04
0323 4C 23 03 JMP $0323

At the end values in memory locations $00 to $04 were all $DB

I was initially confused that all stored values were $DB as I expected 00 & 01 to be $FE, however for zero page indirect, the CPU has to load the target values from memory before the read of the final memory location, and the last value read was $DB which is what was retained on the next read of unoccupied space, so the theory still holds.

[stm]

Mark,

thanks for the detailed investigation of this question and for the amazing accuracy of WinOSI replicating the original hardware!

Stephan

[Mark]

Thanks Stephan!

To add a bit of mystery, it appears with the OSI 510 board, the 6800 reads $FF on unoccupied space which make sense if it is internally pulled up, but the Z80 reads $7E, unrelated to the last data read on the bus as far as I can tell. I need to experiment a bit more to be sure.