Menu
▾
▴
1 Attachments
#507 ISEPIC broken since 2.3 release
The ISEPIC software must be run first with the switch "on" to load the code into the RAM on the cart. I reset to default settings in VICE, then when I turn the switch "on" in the menu, the emulation crashes.
In older VICE (<2.3) this does not happen (you can turn it on) and then you can run the software (attached) and select "copy program" which loads the cart RAM.
mmmh do you have an actual isepic you could run some test programs on? fixing this using the original software is a major hazzle =P
I do... Let me know what you need.
-Pete
On Fri, October 3, 2014 1:43 pm, gpz wrote:
Related
Bugs:
#507ok great, i will come back to it later, when i have written some test programs :)
It seems that the cart cannot possibly bank in the RAM to $F000 in Ultimax
mode before the RAM is loaded by the program, which is what is happening
here. There must be some logic in the cart to keep this from happening
before it's "armed" (blank RAM) like a latch or something.
No idea why it worked before 2.4, though.
I looked briefly at the code differences and it seems the one single
isepic_mmu_translate() was replaced by many smaller read/store/peek
routines. I'm guessing this was translated wrongly somewhere.
-Pete
On Fri, October 3, 2014 2:41 pm, gpz wrote:
Related
Bugs:
#507I take that last part back- the mmu_translate stuff was added to 2.4 and
is just a new part of the cart coce. The rest of the isepic.c looks the
same as far as I can tell.
-Pete
On Wed, October 8, 2014 9:24 pm, Pete Rittwage wrote:
Related
Bugs:
#507"No idea why it worked before 2.4, though."
coincidence i say... we really need someone to properly reverse engineer the schematics. actually given how many clones have been around, its quite surprising that no schematic is floating around.
Last edit: gpz 2014-10-12
prior to 2.3, that is... It worked in 2.2 and 2.1, at least.
I played with the source a little to hack in detection of the cart RAM
being blank, and consequently don't bank in the cartridge in that case.
It gets a lot further - you can load the software and go through the
process of freezing a program. However, the resulting files are basically
blank, so there is still something else causing the underlying issue with
memory handling.
The original cart has a single switch that it asks you to flip back and
forth several times during the prep and freeze, so it must contain a
minimal state machine internally, or else possibly a flag in the RAM to
tell it what state it's in.
However, the code for this in 2.2 contains no clues- it's simple as can be
like a one-button freezer cart.
I'll keep poking at it.
-Pete Rittwage
On Sun, October 12, 2014 1:00 pm, gpz wrote:
Related
Bugs:
#507I played with the real hardware a bit today. Without the RAM loaded (armed) you can flip the switch back and forth and it does nothing at all, so the hardware knows when the RAM has been loaded.
no success in tracking down the schematics so far - even high res pictures of both sides of the PCB might help (if possible, with the ICs pulled from their sockets)
Last edit: gpz 2015-07-01
I will scan this for you in the next couple days.
-Pete
Related
Bugs:
#507Here are 600dpi scans of the front and back. The best I could do was an office document scanner, but it seems clear...
thanks... i'll see what i can do - it's really hard to guess what goes where though, having someone with a cart that has the ICs in sockets (so he can pull them) would help a lot.
edit: i traced it as far as possible... unfortunately even with some guessing there is still too much missing (eg the IC in top right) :(
Last edit: gpz 2015-07-02
please test again - blacky supposedly fixed it some days ago
Yes, it now works as it should.
I tested a copy, run, and "break" and all functioned normally.
-Pete
Related
Bugs:
#507