Post - Forum - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Forum Help

Post Your Message

Previous Messages

Posted By

crock
on 2011-02-10
05:05:48

Re: cartridge programming

Yes, it is for the plus 4 and C16. I have around 8 boards at the moment, and while I've diagnosed them all, it required a *lot* of chip swapping and desoldering.

Yes TLC, that's exactly it. I had come to the same conclusions about the flip flops and was just seeing if there was some exploit out there.

If you have ram or kernal issues the most likely outcome is the ubiquitous blank screen. On a C64 this is easy to find with a dead test or some other cart which bypasses the kernal. For ram, i have a test routine that will run from rom making no use of either the zeropage or stack, and will indicate bad rams either via screen flash or any available I/O line to control LED's.

None of this is any use on a plus 4 though, because the rom/ram banking is all controlled through software and the cartridge selection goes through the kernal, which has already made use of the zeropage and stack before we get to the cartridge jumps. I have made it work by puting it on a rom that replaces the kernal chip but that's extra hassle and it means the kernal rom itself isn't tested.

It's also annoying that you can't bank the high area to ram leaving the low area to rom. I want to completely bypass the IRQ entry points in the kernal but I can't do this without copying my rom code into ram first.

rob

Posted By

TLC
on 2011-02-09
17:29:18

Re: cartridge programming

Yes (...and no... I would have needed to be more precise).

Usual ROM cartridges certainly won't boot up if the Kernal ROM is broken (because they're jumped to by the Kernal reset routine). (They might survive the absence of the Basic ROM, however.)

If the question is, whether some special cartridge could be able to run without the presence of a Kernal ROM (...or anything but the processor + a bare minimum of viable parts), my nose tells met that the answer should probably be yes. I seem to remember a discussion about a rare freezer cartridge that basically "hijacked" the IRQ process by pulling some address lines low, letting the processor fetch some bytes from a purposely mapped-in ROM slice instead of $FFFE/$FFFF of the system RAM (and thus taking control). Exploiting that sort of trick might also help to avoid the Kernal ROM reset routine completely ie. breaking into control before even the reset vector could be fetched from the Kernal ROM.

Posted By

Csabo
on 2011-02-09
10:02:02

Re: cartridge programming

So does this mean that if the two chips containing the ROM are fried, plugging in the cartridge will do nothing?

Posted By

TLC
on 2011-02-09
08:29:25

Re: cartridge programming

IMHO there's no way to coldboot a Plus/4 from an external cartridge, unless the machine is modified.

If you check the schematics (http://zimmers.net/anonftp/pub/cbm/schematics/computers/plus4/plus4-310164-4of4.gif) closely, you can deduct that ROM config (the active ROM configuration) is stored by U21, 74LS175. This 4x flip-flop is cleared by RESET'. Consequently, whenever reset happens (either power-on reset or the reset button is activated), bank 0 will be active (which is BASIC + KERNAL). So you'll have to follow the standard ROM boot process (as described by siz ), or you'll need to invent some way to hijack it.

Posted By

siz
on 2011-02-09
03:22:57

Re: cartridge programming

Your ROM image should start at $8000. There must be a signature in the beginning of the image to be autostarted by KERNAL. The initialization routine maps each ROM slot to the LOW ROM in decreasing order (from 3 to 0) and checks for a signature at $8007. If the characters 'CBM' is found there (bytes $43, $42, $4d) then it checks $8006. If the value found there is 1 then it makes a JSR to $8000. You can place a JMP to your real start there.
Most probably you have to initialize everything in because the ROM init is called before KERNAL RAMTEST and VIDEOINIT.

My code looks like this:
vidinit = $ff81
ioinit = $ff84
ramtest = $ff87
restorio = $ff8a

*= $8000

jmp cold
jmp warmstart

.byte 1
.text "cbm"

cold sei
lda #$bf
sta $fd30
sta $ff08
lda $ff08
and #$10
beq +
rts
+ jsr ioinit
lda $0508
cmp #$a5
beq *+5
jsr ramtest
jsr restorio
jsr vidinit

This one checks for Escape pressed during startup and starts my code only when it is pressed.

Posted By

Csabo
on 2011-02-08
21:34:23

Re: cartridge programming

First, just to clarify, are you developing this for the C16/Plus4?

Regardless, this is an interesting question. Isn't this the case by default? I thought that the first three bytes in the cartridge data have to be a JMP, which is called on cold start. While it's called, the cartridge's "ROM" should be "visible". Though I'm probably confusing terms here, surely one of the real gurus will chime in and enlighten us.

Posted By

crock
on 2011-02-08
19:14:40

cartridge programming

I'm developing a diagnostic cartridge and I would like it to autostart bypassing the kernal, a bit like the c64 ultimax cartridges. Basically I need the cpu to 'see' the cartridge rom in the f000-ffff region on startup. Is this possible?

cheers,

rob