Develop/mgg address decode

LegalizeAdulthood / 6805_SBC

A single board computer built around the Motorola 6805 CPU

GNU General Public License v2.0

1 stars 2 forks source link

Develop/mgg address decode #3

Closed mggates39 closed 2 years ago

mggates39 commented 2 years ago

Simplified and updated mapping to better match the notes given on the last pull request.

LegalizeAdulthood commented 2 years ago

The most complicated chip select is ~RAM1CS because of a couple things:

I intentionally mapped 0x80 through 0xFF to RAM1 so that an additional 128 bytes of zero-page RAM would be available to user code
Because the RTC isn't likely to be accessed frequently, I moved the 16 control registers for the RTC to 0x100 through 0x10F, effectively "cutting a hole" in the mapping of addresses to RAM1. I could have moved it to a chunk of page zero, but I don't think that would simplify the address decoding in any meaningful way; it would still have to be carved out of RAM1 somewhere (and not at the bottom or top)

I downloaded your design from your repo and copied over my test cases for ~RAM1CS and they reported failures, so I think you haven't quite accounted for all the weirdness of the RAM1 address mapping yet.

Also, I noticed that you are computing ~RTCCS but the chip selects on the RTC are active high, not active low.

LegalizeAdulthood commented 2 years ago

One additional thought:

It may be beneficial to put the RTC control registers in page zero so that a stack could grow upwards in addresses out of page zero. However, unlike the 6800 which has a 16-bit index X register, the X register on the 6805 is only 8 bits, so I don't think there's really any benefit here. IIRC, the FORTH interpreter that I saw uses page zero for data and return address stack anyway, so it wasn't expected you would have really deep stack usage.

mggates39 commented 2 years ago

I still have an issue with RAM 1 ~CS. I have the test set up correctly, but it fails right now. The next commit should fix that and then I think it is done.

RTC is good now though. Both my test and your test work

mggates39 commented 2 years ago

the stack grows down form $007F. It can't grow out of the zero page. Since the stack pointer decrements during pushes, the PCl is stacked first, followed by PCH, etc. Pulling from the stack is in the reverse order.

Also, When accessing memory, the seven most significant bits are permanently set to 0000001. They are appended to the six least significant register bits to produce an address within the range of $OO7F to $0040.

LegalizeAdulthood commented 2 years ago

I'm talking about the FORTH data and return stacks. IIRC, the implementation I added doesn't use the 6800 machine stack for either of them, which makes it a little slower than it could be, but opens the stacks up to be larger.

mggates39 commented 2 years ago

Got it.

I have finally finished my updates. Your design is much cleaner, but mine does pass all the tests. Now I can stop thinking about it and start on the 68HC11 board.

Merge this if you want. Then I will pull back all the wonderful changes in master.

LegalizeAdulthood commented 2 years ago

I'll merge this since it modifies a distinct design file. Always nice to compare designs :)