How does VIC-20 detect ROM cartridge address?

[toby405]

I have a 2764 EPROM PCB that connects expansion port pin 13 (BLK5) to EPROM pin 20 which is chip enable (CE). (You can change that to another BLKn but BLK5 is the default.)

How does the Vic-20 know which block is available?

I think if the EPROM chip is not enabled by the expansion port then the data pins on the EPROM should be in floating state and maybe that's how it knows but I don't know electronics - can someone explain?

[wimoos]

Code: Select all

;
	.ORG $A000
	.WORD  <cold start vector>
	.WORD $FEC7 ; default NMI vector
	.BYTE 'A','0',$C3,$C2,$CD ; "A0CBM" signature

The kernel checks for the given byte sequence at $A004 and, when found, takes the contents of $A000 <low byte> and $A001 <high byte> as the address where processing continues.
When a NMI occurs, a similar thing happens but processing then continues at the address pointed to by $A002 and $A003. You should specify $FEC7 if nothing else.

When you connect /CE to, let's say, /BLK3, then this autostart feature will not find the EPROM, and VIC will start normally. Then you can PEEK memory locations 24576-24584 to find if this signature is there, and what the vectors are.


Regards,

Wim

[Mike]

How does the Vic-20 know which block is available?

The VIC-20 does not "know" this - the mainboard logic tries to access memory at some address regardless whether that memory is present or not.

I think if the EPROM chip is not enabled by the expansion port then the data pins on the EPROM should be in floating state and maybe that's how it knows but I don't know electronics - can someone explain?

To expand upon this: the EPROM (or any other memory chip connected to the expansion port) only has enough address pins so it is possible to uniquely address its own contents. The 2764 EPROM in particular has 13 address pins, enough to address 2^13 = 8192 different bytes, which is exactly the capacity of the chip.

Part of the mainboard logic then decodes the CPU accesses for the different blocks, one of the /BLKx signals (x=0..7) is set to 0, all others remain at 1 (this is called negative or active-low logic): when the CPU accesses $0000..$1FFF, /BLK0 is set to 0, when the CPU accesses $2000..$3FFF, /BLK1 is set to 0 ... and so on until when the CPU accesses $E000..$FFFF, /BLK7 is set to 0.

Now, /BLK1..3 and /BLK5 are not used within the computer (except at one place to separate the VIC and CPU bus parts) but connected to the expansion port. When you connect /CS of the EPROM with /BLK5, the contents of the EPROM are mapped to $A000..$BFFF. During power-on or reset, a routine in the KERNAL scans for the autostart signature at $A004..$A008, when it is there, the KERNAL autostarts the cartridge.

Now what does the CPU 'read' at $A004..$A008, when there is no EPROM listening to /BLK5? As you have correctly noted, when no chip responds, the CPU data lines float - but they have a so-called parasitic capacity, which retains the value of the last byte transferred over the data bus. In most cases, this is the high byte of the address being used to access the current byte, here, $A0. The CPU will thus read five times $A0, which is not the autostart signature, and therefore, the reset sequence ends up at the normal BASIC startup prompt.

[toby405]

Excellent, thank you.

[toby405]

Let's say the cartridge contained random data or 8192 bytes of 0xFF for that matter.

The KERNAL will read $A004..$A008 and will not find the signature.

For the rest of the boot process, the EPROM will not see /CS pulled low again, correct?

The only way the EPROM would see an additional access would be if the user did a PEEK in the $A000..$BFFF range or if he started some program that explicitly tried to read from there, yeah?

[Mike]

[...], correct? [...], yeah?

No. The autostart signature is also checked by the KERNAL during NMI (in particular, when the Restore key has been pressed).