Internal and External ROM (EPROM socket onboard)

[MIRKOSOFT]

Hi!


I want to make me sure, so here is my Q:


AFAIK internal ROM has bank 4/5=6/7 and external ROM bank 8/9=10/11
To activate internal ROM (which is onboard in EPROM socket) I must to hold CONTROL key during startup/reset.


How to activate external ROM and where is?
I know only that empty socket is placed in REU 1700/1750, but I'm not sure...
Also REU 1764 was designed for Commodore 64, so is there empty socket?


If I'm writting only mistake, please explain me all what you can about external ROM...


Many many thanks for every help/info...


Miro

[BigDumbDinosaur]

Hi!


I want to make me sure, so here is my Q:


AFAIK internal ROM has bank 4/5=6/7 and external ROM bank 8/9=10/11
To activate internal ROM (which is onboard in EPROM socket) I must to hold CONTROL key during startup/reset.


How to activate external ROM and where is?
I know only that empty socket is placed in REU 1700/1750, but I'm not sure...
Also REU 1764 was designed for Commodore 64, so is there empty socket?


If I'm writting only mistake, please explain me all what you can about external ROM...


Many many thanks for every help/info...


Miro

All of the answers to your questions are covered at length in Mapping the Commodore 128, as well as several other documents that are available right on this website.  How about if you start READING some of them?

[Hydrophilic]

The software is activated when you first turn on the computer.  Some software might do special things when you press CTRL (or some other key), but that is not required... who ever programs the software can make it do pretty much anything.

For how to "activate" the software (other than the reset routines), you have to consult the documentation of who ever made it.  There is no standard, except maybe the reset vectors, but they are optional.

[BigDumbDinosaur]

The software is activated when you first turn on the computer.  Some software might do special things when you press CTRL (or some other key), but that is not required... who ever programs the software can make it do pretty much anything.

For how to "activate" the software (other than the reset routines), you have to consult the documentation of who ever made it.  There is no standard, except maybe the reset vectors, but they are optional.

As usual, one picture is worth a thousand words:

Code Select Expand

;================================================================================
;
;C-128 OPTION ROM DEFINITIONS
;
or_lo    =$8000                ;low ROM ($8000-$BFFF)
or_hi    =$C000                ;high ROM ($C000-$FFFF)
;
;
;    ROM header offsets...
;
or_cs    =$00                  ;cold start entry
or_ws    =$03                  ;warm start entry...
;
;    â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"
;    warm start entry is ignored by CBM kernel
;    â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"
;
or_id    =$06                  ;ROM ID...
;
;    â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"
;    $00     = ROM ignored by kernel
;    $01     = started by kernel POLL routine
;    $02-$FF = started by kernel PHOENIX routine
;    â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"â€"
;
or_key   =$07                  ;"CBM" recognition key
or_free  =$0a                  ;start of program & data area

In order to understand how this works you have to know about two functions that are in the kernel ROM.  The first is POLL, which is called relatively early during reset.  The other is PHOENIX, which is called when BASIC is started following the completion of reset.

POLL, as the name suggests, polls the four possible places where option ROM can appear:

• Internally at $8000
  
• Externally at $8000
  
• Internally at $C000
  
• Externally at $C000

"Externally" means the ROM is in a cartridge plugged into the expansion port.  "Internally" means the ROM is in the U36 socket on the C-128's motherboard.

Speaking of internal ROMs, any JEDEC 27C128 or 27C256 EPROM (150 ns or faster) will work as U36 (don't try to use 27C512s, however).  I use 27C256s (32K) because I have a bunch of them laying around and can arrange them to be low or high option ROMsâ€"or both.  Just set up your EPROM burner so it only writes to the first 16K of the ROM if you use a 27C256 and want the ROM to appear at $8000.  If you want it to appear at $C000, leave ROM locations $0000-$3FFF erased (all $FFs) and start your code at $4000.  If you want the ROM to appear in both locations, be sure to write a valid header at $0000 and $4000.  I have not tested any of the similarly sized EEPROMs, although I see no reason why they shouldn't work.

Getting back to POLL, for each of the four possible ROM locations, POLL begins by testing for the presence of the character string CBM at $x007-$x009, where $x is either $8 or $C.  If the CBM string is absent, POLL skips to the next location.  Otherwise, POLL will read the ROM ID at $x006 and log it into the option ROM table maintained at $0AC1 in RAM-0.  It is here where the ROM ID matters.

If the ROM ID is $00 or $02 through $FF, POLL moves on to the next ROM location.  However, if the ID is $01, the ROM is "autostarting" and POLL will effectively execute JSR $x000, which is the ROM's cold start entry point.  POLL expects to find a JMP <ADDR> instruction at $x000, where <ADDR> is the cold start code in the ROM, usually located at $x00A.  The cold start code would then perform whatever steps are required by the ROM's application, such as setting up a different keyboard, adding to or replacing part of the kernel, etc.  At the end of the cold start code, control can be returned to POLL with RTS, allowing POLL to continue checking for more option ROMs.  In some cases, a  ROM may not return control, often characteristic of game cartridges.  If this happens, the ROM must complete the system initialization steps that it needs in order to function.

Once POLL has polled all ROM locations, the normal reset functions will continue, culminating in a JMP ($0A00) instruction, which takes the machine into the BASIC cold start code at $4000 in low BASIC ROM (unless an autostarting option ROM modified that address). The BASIC cold start code initializes all BASIC pointers and locations, and then, as a last step, calls PHOENIX.  PHOENIX first scans the option ROM table at $0AC1 that was earlier filled in by POLL.  Here again, if the ROM ID is anything other than $00, PHOENIX will (in effect) execute JSR $x000 to start the ROM.  Assuming the ROM ends its cold start code with RTS, control will be returned to PHOENIX and the process will be repeated until all ROM locations have been processed.  The last step in PHOENIX before returning to BASIC is to attempt a boot from the floppy disk.

In general, option ROMs should not be autostarting unless the intention is to make significant alterations to the operating environment or to take complete control of the machine.  In most cases, the ROM should have a non-autostarting ID so a full reset can occur.  When BASIC gets to the point where PHOENIX is called, all BASIC pointers and variables will have been initialized.  A option ROM could, if it chooses, make some changes to the BASIC environment, such as moving the start of BASIC text address from $1C01 to another location, or moving the end of BASIC text from $FF00 to a lower address to reserve RAM for some other puprose.  In a ROM I am working with, I relocate the bottom of variable storage in RAM-1 to a higher address so I can use some RAM-1 space for buffers and pointers.

Lastly, when PHOENIX calls logged option ROMs, the kernel will not be in visible address space.  If a ROM's cold start code requires kernel services it must either map in the kernel (not possible if the option ROM is at $C000) or must use JSRFAR to get to the kernel routines.

[Hydrophilic]

Wow, that's a pretty good explaination of the reset routines!  To summarize, the ROM gets activated soon after reset if it has ID 0 (autostart), or later after BASIC is initialized (any other ID), or never if the header is invalid. 

Assuming it is called, it may do certain things if you're holding down a "special" key (like CTRL).  So you just never know... and extrnal ROMs (cartridges) are even worse because they can have special hardware features too.

[hoss48458]

Thanks BDD there for an excellent explantion of POLL and PHONIX rountines.

[BigDumbDinosaur]

To summarize, the ROM gets activated soon after reset if it has ID 0 (autostart), or later after BASIC is initialized (any other ID), or never if the header is invalid.

You misunderstood.  Assuming the CBM key is present in the ROM at the correct address, POLL will start the ROM only if the ID is $01.  PHOENIX will start it if the ID is anything *but* $00.  If the ID is $00 the ROM doesn't exist as far as the kernel is concerned, but can be accessed by writing the appropriate mask into the MMU configuration register at $FF00.

Assuming it is called, it may do certain things if you're holding down a "special" key (like CTRL).  So you just never know... and extrnal ROMs (cartridges) are even worse because they can have special hardware features too.

Correct to a point.  In order for an option ROM to intercept and act upon keypresses the jiffy IRQ must be running so the keyboard can be scanned.  Otherwise, the ROM must scan the keyboard, which is a complicated undertaking if the option ROM is mapped in at $C000 (you can't directly access the kernel in such a case).  The interesting paradox is no option ROM is visible during interrupt handling unless it replaces the kernel and in doing so, modifies the front end of the interrupt handler to map in the option ROM.  Otherwise, code must be downloaded into RAM-0 and wedged into the IRQ handler to map in the ROM and execute the code therein.

It would have been nice if the MMU had been equipped with a few more preconfiguration registers so alternative memory maps could be defined without disturbing the ones used by BASIC.  Then it would be very easy to divert interrupt handling to option ROM.  However, it can be done despite that shortcoming.  I'm in the early stages of writing a dual port ACIA driver for the 128 that runs out of the internal option ROM and uses IRQs for I/O processing.

[Hydrophilic]

POLL will start the ROM only if the ID is $01

That's kind of odd, but looking at the code again, you are correct.

PHOENIX will start it if the ID is anything *but* $00

Now that is what I was thinking of when I made my last post.  Which brings up an interesting point.  If it has an autostart ID (1), then ROM will get called TWICE ... through the same vector.

I always thought it was weird that there are two vectors in the ROM header, but the KERNAL only uses one of them.  I wonder if it is a bug and POLL was suppose to use the "cold" vector and PHOENIX was suppose to use the "warm" vector?

I agree, CBM should have left 1 or 2 unused PCRs for the programmers.  A few more in the MMU or a few less used by BASIC.

BASIC does need fast access to RAM0 and RAM1, and some configuration with all the BASIC ROMs, but it doesn't need 2 ROM configs.  In other words, it could easily get away with only 3 instead of all 4 PCRs.

And the MMU can fully decode the lower 4 bits of the address.  Since the highest register is $0b, they could have added another 4.  Or how about 3 to make a nice 8-byte hole at $ff00~ff07 ?

Your ACIA project sounds interesting.  Would it be any more difficult to have it in external ROM?  That would make it a complete 'plug-n-play' device.  (I'm assuming you interface through a cartridge and not the user port)

[BigDumbDinosaur]

Which brings up an interesting point.  If it has an autostart ID (1), then ROM will get called TWICE ... through the same vector.

That's correct.  I examined the PHOENIX code and determined that it doesn't check the ID to see if it's $01 or not.  It only checks that the ID isn't $00.  I believe Commodore's thinking was that a ROM with ID=$01 would not return control to POLL and would take over the entire system.  Hence PHOENIX would never be called and a "double start" wouldn't occur.  Alternatively, by the time PHOENIX gets called, a full initialization will have occurred, the DEJAVU flag has been set and the ROM, upon being called a second time, would know by testing DEJAVU that it had already been called by POLL.

I always thought it was weird that there are two vectors in the ROM header, but the KERNAL only uses one of them.  I wonder if it is a bug and POLL was suppose to use the "cold" vector and PHOENIX was suppose to use the "warm" vector?

It is intentional.  From what I recall from back when I had the C-128 developer docs from CBM (courtesy of Fred Bowen), the idea was after the ROM was called by PHOENIX it (the ROM) would store some anchor code in low RAM and modify the system vector at $0A00 to point to that anchor code.  The code, in turn, would expose the ROM and JSR to the warm start address.  That way, the ROM could fix up any vectors it had changed, but had been changed back due to RUN-STOP/RESTORE.  After doing its thing, the anchor code would direct the machine to the BASIC warm start vector at $4003.  This is the model I am using with my ACIA ROM.

Your ACIA project sounds interesting.  Would it be any more difficult to have it in external ROM?  That would make it a complete 'plug-n-play' device.  (I'm assuming you interface through a cartridge and not the user port)

It will be plugged into the cartridge port and will have a pass-through, as well as a jumper to set it up as IO-1 or IO-2.  I've thought about having the "BIOS ROM" on the card, mapping in at $8000, but didn't want to complicate the design at this time.

Right now, I'm waiting for the PC boards to arrive, so running the ROM in the U36 socket is handy for testing.  Also, the purpose of this ACIA card is to connect to one of the serial ports on my UNIX box, which is where I do my software development.  Hence, it doesn't have any frills.    Code that will be in the ROM will be able to input Motorola S-records coming from the UNIX box, decode them and store the results into RAM.  It'll be a lot faster than trying to do the editing and assembly on the C-128.

BTW, the ACIA I chose is the NXP (formerly Phillips) 2692A, which has dual ports, on-chip FIFOs and can run both ports at 115.2 Kbps.  That speed isn't practical on the C-128, even in FAST mode, as the potential is there for about 46,000 IRQs per second.  The 128 simply can't keep up with that pace.  Maximum practical speed will be 38.4 Kbps.

If there was sufficient interest, I could produce a version with onboard ROM.  I'd have to have orders for at least 20 cards to make it economically viable.  Incidentally, the card would work with a C-64 (or the C-128 running as a C-64), but, of course, the ROM wouldn't be able to do anything.  The driver would have to run in RAM.  I could see stuffing it under the BASIC ROM, with just the first page of the code in RAM.  That would allow me to link it into the interrupt handler and have that front end switch out the BASIC ROM as needed.  I could also bury the four data FIFOs under the ROM as well, thus limiting the intrusion on BASIC program space.  Most likely, the maximum practical speed with the C-64 would be 38.4 Kbps on one port.  Two port operation would be possible, but probably pointless.  What would be able to process to calls at the same time?

[MIRKOSOFT]

...in my internal socket of C128DCR is BASIC 8.0 & GEOS 128 2.0 ROM with switcher.


I have on flat C128 Turbo Assembler 128 ROM, but I want to integrate both to the C128DCR.


So, I know about Internal/External ROM - now where to place TASM128 if is on-board socket occupied?


I have also 1764 REU 1,5MB - is there socket for external ROM? Or how to do it to use both?


Many thanks for help.


Miro