I/O mapped to F0xx

[Michael]

I've got my I/O mapped on the 6502 board to F0xx (A8..A11 on and A12..A15 off). This is working since I am both reading and writing characters via the ACIA (including Rx interrupt). Yay!

I assumed that mean that 256 bytes (F000 through F0FF) are mapped to I/O, correct?

My ROM straddles this range and I have code on either side. It appears that when I call my function at F100, things go sideways (hang).

My assembler just fills the 'reserved' 256 bytes with NOPs (rather than code that's going to be called/used). When I call Execute, I die.

[Editor]

I've got my I/O mapped on the 6502 board to F0xx (A8..A11 on and A12..A15 off). This is working since I am both reading and writing characters via the ACIA (including Rx interrupt). Yay!

I assumed that mean that 256 bytes (F000 through F0FF) are mapped to I/O, correct?

My ROM straddles this range and I have code on either side. It appears that when I call my function at F100, things go sideways (hang).

That is correct.

In effect the /IORQ bus control line takes priority over the /MREQ bus control line.

/IORQ itself is based on the /IOADDR named output of the IORQ Bank Select comparator (i.e. your DIP switch 256 byte I/O bank select settings).

This logic is all defined by the PLD logic statements, which provides the ultimate MECB Card implementation flexibility.

ie: For the 6502 PLD the default Bus Control logic I setup is:

Code: Select all

/*
 *
 * Logic: 6502 CPU Card - Bus Control  
 *
 * ecb_mreq : ioaddr not asserted, while clk high.
 * ecb_iorq : ioaddr asserted, while clk high.
 * ecb_clk : clk
 * ecb_rd : cpu_rw is high, while clk high.
 * ecb_wr : cpu_rw is low, while clk high.
 *
 */

ecb_mreq = !ioaddr & clk;
ecb_iorq =  ioaddr & clk;
ecb_clk = clk;
ecb_rd = cpu_rw & clk;
ecb_wr = !cpu_rw & clk;

The default PLDs 56K / 8K Memory Map is then defined as such:

Code: Select all

/*
 *
 * Logic: 6502 CPU Card - Chip Selects for 56K RAM 8K ROM 
 *
 * cs_rom : ROM address space (0xE000 - 0xFFFF), while ecb_mreq asserted.
 * cs_ram : RAM address space (0x0000 - 0xDFFF), while ecb_mreq asserted.
 * cs_spare : Unused, but assigned to replicate ecb_iorq.
 *
 */

cs_rom = ecb_mreq & a15 & a14 & a13;
cs_ram = ecb_mreq & !(a15 & a14 & a13);
cs_spare = ioaddr & clk;

[Michael]

Thanks.

And here I was hoping for an easy answer for why I fail when I call F100 ...

[epaell]

As a really basic test, can you map the HelloWorld program to start at $F100 in the ROM to see if that works?

[Editor]

Thanks.

And here I was hoping for an easy answer for why I fail when I call F100 ...

Apologies. I think I must have initially misinterpreted, and read it as hanging when you call code in the I/O allocated bank.
Of course, $F100 is beyond $F0xx. I must be too distracted today!

So, in answer to your question, I don’t see any reason this would be caused by your $F0 I/O bank allocation, assuming there is nothing in ROM to branch to code (or refer to vector tables etc.) in the $F000 - $F0FF space.

[Michael]

As a really basic test, can you map the HelloWorld program to start at $F100 in the ROM to see if that works?

Good plan.

[Michael]

The 'F0xx issue' was red herring.

It's alive!

This is the super minimal version of the Hopper Runtime (virtual machine on the 6502), less than 8K. Full symbolic debugging experience over the serial port with the IDE running on Windows.

Next:

• program a CPLD for 48K RAM, 16K ROM to get the full version of Hopper with all the language features working

• try running at 8MHz again (failed when I tried before)

• figure out the Motorola timer (to replace the functionality I usually get from the WD 65C22 VIA)

• get Dave's recent VGM work running on the sound chip ..

[epaell]

Awesome!

[Michael]

program a CPLD for 48K RAM, 16K ROM to get the full version of Hopper with all the language features working

Success! Full Hopper 16K running now.

try running at 8MHz again (failed when I tried before)

Still failing to increase the 6502 speed from 4MHz to 8MHz. Maybe it is running but the serial communication is failing since I don't use hardware control (but I don't have an issue with the same chips on my SBC - only big difference is the SRAM chip but it appears to be quite fast)?
What's the fastest others have run this board at? Which components are the weakest link, speedwise? The EEPROM?

Running super reliably at 4MHz though.

[lenzjo]

This is the super minimal version of the Hopper Runtime (virtual machine on the 6502), less than 8K. Full symbolic debugging experience over the serial port with the IDE running on Windows.

Any plans for porting this to Linux?