How does the Epyx Fastload cartridge boot?

[Leif Bloomquist]

Hi all,

I'm interested in hearing about how the Epyx Fastload cartridge boots up, if
anyone knows. I've always been curious about it, and now I have a specific
need: I'm trying to get it to work with the Cardco Cardboard/5 cartridge
port expander.

The Cardboard/5 has several switches that let you override GAMEROM and EXROM
for non-standard cartridges, and it looks like I might have to do that. (It
isn't even recognized in the so-called standard configuartion of the
Cardboard/5).

So I'd be interested in getting a high-level description along the lines of
"At power-up it holds these lines low, it appears in memory at XXXX, it
copies itself to XXXX, and then does this..." up to the appearance of the
READY prompt.

Maybe it's not even possible for it to work in an expander?

Any info welcome.

Regards
Leif

[David Evans]

Post by Leif Bloomquist
I'm interested in hearing about how the Epyx Fastload cartridge boots up, if
anyone knows.

Fastload is a little complex, involving a little bit of extra hardware
(some capacitors, etc.) that make the cartridge appear and dissapear in
memory. There was an article in The Transactor about how it worked, but
a quick look through Craig Bruce's archive didn't reveal it.

[David Evans]

Post by David Evans
There was an article in The Transactor about how it worked, but
a quick look through Craig Bruce's archive didn't reveal it.

It is, I believe, called "Now You See It, Now You Don't -- C64
transparent cartridges", in Volume 8, Issue 03, November 1987.

[Cameron Kaiser]

Post by Leif Bloomquist
So I'd be interested in getting a high-level description along the lines of
"At power-up it holds these lines low, it appears in memory at XXXX, it
copies itself to XXXX, and then does this..." up to the appearance of the
READY prompt.

I don't remember the exact details (actually, I remember Nicolas Welte and
I were discussing this at one point, so he might recall), but the FastLoad
has some magic to make it transparent.

Officially there is one 8K ROM, which normally occupies $8000-9fff. There
is also some I/O line logic that the cartridge uses to occupy both $de00
and $df00 iospace (which is why it doesn't play nice with SwiftLinks,
REUs or geoRAM). At $de00 is a register to the cartridge's hardware that
causes it to hide its main 8K ROM at $8000.

How does the cartridge stay functional? By a clever trick in hardware, the
last 256 bytes of the 8K ROM always remain accessible at $df00, and all the
vectors point to this stub. This stub then re-enables the cartridge ROM
and runs the main routines within it. You can disassemble the stub (it's
very short) by looking at that 256-byte section. From what I've analysed of
it over the years, the routine at $df06 seems to turn the cartridge ROM on
(one example is $df6a, which is the FastLoad warm start vector).

For a fun little secret message, run this:

.word $c000
* = $c000

scotty jsr $df06
ldx #0
lup0 lda $8000,x
sta $0400,x
inx
bne lup0 ; d0 f7
rts

ready.
sys49152

--
Cameron Kaiser * ***@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **

[Leif Bloomquist]

Post by Cameron Kaiser
is also some I/O line logic that the cartridge uses to occupy both $de00
and $df00 iospace (which is why it doesn't play nice with SwiftLinks,
REUs or geoRAM). At $de00 is a register to the cartridge's hardware that

Ack - the whole point of this exercise was to use my Epyx Fastload and the
1750 Clone REU cart (that I picked up at the LUCKI Expo) at the same time.
Guess I'm out of luck. The Super Snapshot 5.22 worked with the 1750 Clone
though (tried that at the Expo), so I might have to switch.

Post by Cameron Kaiser
vectors point to this stub. This stub then re-enables the cartridge ROM
and runs the main routines within it.

Ahhh, so that's what is happening! I don't think the Cardboard/5 will work
in that case.

By manipulating the Cardboard/5's switches in a particular order, I was able
to get it to the point where an SYS 57194 call would enable the Epyx
Fastload and it would work fine, but the EXROM line (visible through a LED
on the Cardboard/5) would flicker on and off whenever I was using a Fastload
command. It was bizarre, it looked just like a drive activity light. So
that was the cart ROM being rapidly switched in and out.

Even then, it crashed if tried to use the 1750, which you explained above.
So much for that.

Post by Cameron Kaiser
.word $c000
* = $c000

I'm using Turbo Assembler 5.2, and in the past I've tried to place code at
$c000, but it just crashed when I went to compile. I assumed it uses $c000
as scratch space? What assembler are you using?

Also, what does the .word opcode do in that program? Is it needed? It
looks like it puts the bytes $C0 00 at the start of the program, which
doesn't seem right?


Regards,
Leif

[Cameron Kaiser]

Post by Leif Bloomquist

Post by Cameron Kaiser
is also some I/O line logic that the cartridge uses to occupy both $de00
and $df00 iospace (which is why it doesn't play nice with SwiftLinks,
REUs or geoRAM). At $de00 is a register to the cartridge's hardware that

Ack - the whole point of this exercise was to use my Epyx Fastload and the
1750 Clone REU cart (that I picked up at the LUCKI Expo) at the same time.
Guess I'm out of luck.

Yup. :( It doesn't work at all, I've tried many, many times. That was
part of the reason why I wrote VDC support into HyperLink so that I could
have my cache and eat it too. ^_^

[yoink]

Post by Leif Bloomquist

Post by Cameron Kaiser
.word $c000
* = $c000

I'm using Turbo Assembler 5.2, and in the past I've tried to place code at
$c000, but it just crashed when I went to compile. I assumed it uses $c000
as scratch space? What assembler are you using?

This is pseudo-xa. Ironically, I just hand-assembled it in the FastLoad
monitor, as it happens :P

Post by Leif Bloomquist
Also, what does the .word opcode do in that program? Is it needed? It
looks like it puts the bytes $C0 00 at the start of the program, which
doesn't seem right?

Yes, that's if you're cross-compiling an xa source file to disk (it writes
the starting address). Force of habit. ^^;;

--
Cameron Kaiser * ***@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **

[Nicolas Welte]

Post by Cameron Kaiser

Post by Leif Bloomquist
So I'd be interested in getting a high-level description along the lines of
"At power-up it holds these lines low, it appears in memory at XXXX, it
copies itself to XXXX, and then does this..." up to the appearance of the
READY prompt.

I don't remember the exact details (actually, I remember Nicolas Welte and
I were discussing this at one point, so he might recall), but the FastLoad
has some magic to make it transparent.

Since I don't own such a cartridge, and don't remember this at all, it might
be another person you discussed this with ;) Markus Brenner maybe?

Nicolas

[Nick Coplin]

Post by Cameron Kaiser
Officially there is one 8K ROM, which normally occupies $8000-9fff. There
is also some I/O line logic that the cartridge uses to occupy both $de00
and $df00 iospace (which is why it doesn't play nice with SwiftLinks,
REUs or geoRAM). At $de00 is a register to the cartridge's hardware that
causes it to hide its main 8K ROM at $8000.
How does the cartridge stay functional? By a clever trick in hardware, the
last 256 bytes of the 8K ROM always remain accessible at $df00, and all the
vectors point to this stub. This stub then re-enables the cartridge ROM
and runs the main routines within it. You can disassemble the stub (it's
very short) by looking at that 256-byte section. From what I've analysed of
it over the years, the routine at $df06 seems to turn the cartridge ROM on
(one example is $df6a, which is the FastLoad warm start vect

On the electrical front, accessing the ROM code which mapped to DFxx
then writes/reads to DExx. This second access discharges the capacitor
which bringing the ROM at 8000-9FFF into view. Jumping to the ROM lets
more code run, then it jumps out back through the DFxx tables. The
capacitor is part of a simple RC ciruit which RESET, ROML and DExx
(IO1) lines activate and after a small delay (10ms?) deactivates
removing the ROM at 8000-9fff from view. It is the RESET which brings
it into view at boot!

Pretty neat - Nick