The basic idea of that circuit is OK: The only way to see HIRAM at the expansion port (indirectly) is to attach a cartridge there (i.e. to set the GAME/EXROM lines like a cartridge was attached). If a cartridge is attached and the CPU accesses an address range at $a000...$bfff the control line /ROMH shows directly the state of HIRAM.

But the working principle of that device is even dangerous: It tries to use a moment when AEC changed already (i.e. A12..A15 are not driven but only pulled up with resistors), but the CPU does not drive the address lines yet. In this moment it changes A14.

The timing window is very short and controlled by gate delays and RC elements. One has to find the right setting to get it to work on a certain C64, because all of them have a slightly different timing. And the timing even changes over temperature.

What happens if the timing does not fit to the C64? In one direction simply HIRAM cannot be detected and the external kernal does not work. In the other direction A14 is driven against the CPU address pad driver. This may still work if the driver on the cartridge is stronger than the CPU. But the CPU will become hotter and may even be damaged possibly.

That's why I do not recommend to build the cartridge shown at that PDF. It may damage you C64. But it is possible to build a kernal cartrigde with a HIRAM detection over ROMH but with a safer operation One has to use a different way to avoid bus contention.

The battery buffered RAM is used to write a kernal to the cartridge directly using the C64 AFAIK. Something which is also possible with modern flash memory today.

Edit: I applied for the bounty. In case it's assigned to me I'll write and release a functional description of the operating principle in the first 60 days.
_________________

Very ingenious solution.

Jim

Will this be possible for the C128 as well in c64 mode. ?
_________________

According to the description in 64'er it's possible for the C128 as well but requires different timings. There was a different PCB for the C128 version.

The C64 Kernal cartridge bounty has been assigned to Skoe.

Another very worthy bounty I must contribute to... When payday comes i'll add to the pot... Looking forward to see what you come up with Skoe... I'll test it with my eprom PLA if you like...

I gotta say, this topic went WAY farther than I could have hoped, Looking forward to your progress Skoe.

A lot of good things have been learned and brought out in this forum.

Nice..
_________________

Seems like it's the right person trying to get it done.

I wish you good luck skoe.

Found this link that shows one made by Clocky. However, I do not know if it has the problem that was brought up on this forum. Only problem is that it has that internal wire issue going on. Which looks a lot more complicated then just remove a chip and inserting another chip.

That's a very simple way using no "tricks". However, you must modify your 64 internally to put the chip enable for the kernal ROM onto an unused cart pin for it to work.
_________________

I threw my few bucks in the pot as I could then have my "stock" units bot LtK friendly and JD "happy" without the two every converging!

-maraud
_________________

Today I added a first publication to the bounty page:
http://commodorebounty.com/ind...;Itemid=69

Thomas
_________________

I understand it's an engineering challenge, but all that just to avoid one wire clipped inside the machine?
_________________

Interesting read Skoe, not that I understand all technical details. I wonder if Gideon wants to try it in the Ultimate (if it can handle it).

Imagine all Ultimate users being able to test it on all their different computers, that would be good data.

Quote:

I understand it's an engineering challenge, but all that just to avoid one wire clipped inside the machine? Smile

It's been discussed before so... let's agree it's easier, anyone can plug in a cartridge, not everyone can do the other stuff.

... It's so easy to fix in WinVICE, why bother with it at all?

I would perfer to just insert the kernal cartridge.

Great project.
_________________

I've read Skoe's document and was pointed to the bounty this morning (things got a little hot over at Forum64).

The basic principle of finding out the state of the Hiram line by applying a different address for a split cycle is the same on all the external Kernal circuits. However, I'd like to throw in some improvements for Skoe, as I have made such a circuit in 1999 already named "Flash Gordon" (was demonstrated at a user meeting some time later, but never released as a product).

Using the DMA line is not a good idea, especially in combination with an asyncronous 25MHz clock. Pulling DMA for a split cycle means that addresses that are already valid on the bus are removed for that split cycle. However, the RAS line may go low during that short time (remember 25MHz is async, so it's a statistical thing), and the false address is stored within the Ram chips -> this cycle would read the wrong address, possibly crashing the machine.

It is perfectly OK to pull low on A14 while the CPU is driving the bus. The reason for this is that NMOS and HMOS circuits do not have push/pull FETs on their output pads, but an always-on-pullup-FET. What looks like a short at first glance is a perfectly normal operation, as it happens all the time in such old technology. No chip (especially not the CPU) will get any hotter than in normal operation when you pull A14 low.

I'll dig out the source code of my Flash Gordon cart and adapt it to the "Nordic Replay" cartridge, which is the ideal base for this. Nordic Replay is sold in Europe and the US (Retro-Donald in Germany and Mike from California, who also sells EF kits), and with the MACH chip in a socket, it can easily be changed to be the "Flash gordon" that I've designed back then.

I won't claim the bounty, but support Skoe in debugging the circuit. The approach is correct, it's just not perfect yet.

Jens

Unseen,

I was just pointed to that external ram replacement on Forum64 - my mistake.

However, it's possible completely without additional external ram, as I described over at Forum64. Hope that Skoe will cool down a bit - I know it's bitter, but there's an easier way.

Jens

But the bounty was not about finding the easiest way.

If you made your circuit in 1999 and it didn't fully work for some reason then perhaps this new approach is worth a try? So let him do it his way, if that doesn't work perhaps then it's easier to discuss another approach.

I'm more then happy about helpful hints. But if somebody hides the solution for many years and comes up when somebody else did it, just to say "I was the first one", that's not help at all.

As you realized already much of the ranting you wrote did not fit to the concept from my paper. It contained _one_ useful hint, that you measured that the A14 output of the 6510 can be pulled low without using the DMA line.

This can really simplify the concept and even shows that the old circuit in this document is not dangerous, but only instable. In case I decide to continue with this project I'd consider the simplification.

Thomas
_________________