Update (Q2 2020) - Various interesting additions..
Wow, I didn't realise how old this part of the project site is. I have done a fair few things since then:
This now means I have a lot of power when I need it - for example being able to run off interrupts. I am quite pleased with how I ended up slotting this in to the interpreter. The interpreter stores all keywords as tokens to speed up execution and tokens are identified by bit 7 being set in the code. This means 128 tokens maximum - which is fine for BASIC, but as there are at least 56 mnemonics in the 6502, I wouldn't be able to treat them as normal tokens.
My solution was that the inline assembler is a kind of sub-interpreter, invoked by the main interpreter whenever it encounters a '.' (dot) symbol as the first non-whitespace character. At that point the in-line assembler does the decoding etc. So 128 token limit side-stepped.
My other problem is how to treat labels and variables. I decided fundamentally to use the same variable name space as the main code - which is handy because variables can be set in BASIC and then used by the assembler. This makes for a potentially very powerful macro assembler.
My final problem was resolving address locations. Some addressing modes of the 6502 are ambiguous such as zero page and absolute - no way to tell which addressing mode you want until the address is known. But if that address was coming from a variable which could be a forward reference and hence has not been declared yet then what to do? The solution is to do one pass where you assume everything unknown is zero page, then a second pass with forward references filled. This may result in some zero page modes becoming absolute - which takes an extra byte. If this happens then all the forward references are now wrong, until they are reached and the value updated! The solution is to do a third and final pass which uses the correct values.
Hence the reason this is a 3-pass assembler.
What can I do with this that was not possible in BASIC? Well aside from the obvious massive speed increase, it would be impossible to do effects like this, which rely on handling interrupts and micro-second precision to change video memory settings.
(Nov 2018) - Enhanced memory map and decoding - 128K RAM and 64K ROM
I'll copy the notes from my schematic by way of an explanation..
My computer uses 16K ROM and 48K ROM (minus addresses mapped to IO), but I have 64K EEPROM and 128K SRAM chips on the breadboard. The 65c02 can only address 64K through its 16 bit address bus, so the route I will go down is memory banking - the ability to switch out different parts of the total RAM/ROM in to the 16 bit address range.
The full set of features is as follows:
- Ability to switch ROM out for RAM (top 16K of memory map)
- Any write to ROM should select RAM, enabling write to RAM without switching
- Ability to select which 16K of ROM is addressable by 6502
- Ability to select which 32K of RAM is addressable by 6502
- Ability to have a continuous top 32K of RAM (currently B000-BFFF is memory mapped IO
So I need somewhere to hold the RAM and ROM bank numbers to be decoded to switch in the correct part of memory, and also the ability to switch ROM out altogether to enable a full 64K of RAM (minus IO window). I also need to move the IO window from B000-BFFF (a 4KB block) to somewhere lower and make it smaller too as no IO device needs more than 16 bytes addressing space.
- Breadboard space only allows for 3 ICs for address decoding and R/W enable
- Use only available ICs - 74HCT138, 74HC00, 74HC02
- Limited pins to decode RAM/ROM - but Port B of 65c22 number 1 is available
I engineered the features through 3 solution approaches as...Read more »