Jump to content
TomSon

FE bank switching (this time on Tiara)

Recommended Posts

I've finally obtained a NTSC 2600 for testing and tried my Tiara hw out on it: while playing

a whole bunch of different games I saw on this setup that the FE code was unstable: Decathlon

and Space Shuttle crashed, Robot Tank glitched (very rarely) but Thwocker worked just fine.

That surprised me a bit since much more complex things like AR or DPC(+) work.

However, FE was troublesome before, last time on the 7800, and I never fully understood why

certain timing changes helped so this didn't surprise me that much.

 

So, I've tested again on 7800 and two 2600 PAL where everything worked except Space Shuttle

on one PAL 2600 - sometimes it crashed which so far slipped through my testing.

At this point I decided to entirely rewrite the code from scratch, not based on the documentation

I saw before but using a simpler version that just checks rts/jsr access to the topmost stack

by the order of the incoming accesses to 1fe/1ff. Again no luck - Space Shuttle or Robot Tank now

work stable but Decathlon refuses to come up. I add/remove sanity checks (like whether the following

adr. is the one it's supposed to be) but this doesn't help either, however it does expose a strong hint

why Space Shuttle didn't work - a specific 1ff bus access pattern. Which gives me another idea,

because I had a very strong gut feeling anyways that all I'm doing is way too complex:

 

so, I ignore all documentation I might have read, e.g. that opcodes are detected on the bus (very

unlikely Imo, never tried that) or that the previous cycles adr. is used, or the next ones.

Because in hw the most easy thing to have implemented would have been to just wait for 1fe on

the bus and always latch the next cycles data bit for the bank address line.

 

And this is what I did and you know what: this minimal FE bus routine works flawlessly on all my

consoles, including the 7800. This increases my confidence in my theory quite a bit so I've

just got to ask: is there some proof that the FE bank switching method does use a more complex

mechanism than waiting for 1fe (or maybe more adresses $1xy with xy even, you'd just have to

ignore adr. lines). ?

 

Because from where I am standing everything else seems to break one game or the other here.

 

Thomas

p.s.

quite a long text but I thought maybe it's interesting to see how I attack something like this from

a bus emulation point of view

 

p.p.s.

I've just hooked up all my consoles and successfully tried this behavior with all the FE games I've got,

took a while...

 

post-50731-0-16084200-1502465563_thumb.png

  • Like 7

Share this post


Link to post
Share on other sites

I think your reasoning is correct. It is what is also implemented in 6502.ts (https://github.com/6502ts/6502.ts/blob/master/src/machine/stella/cartridge/CartridgeFE.ts, line 98ff) and it works flawlessly there. For an "official" reference, check out David Crane's patent that alex_79 dug out here: http://atariage.com/forums/topic/266200-my-2600-playground/?do=findComment&comment=3775337 . I think Kevin Horton's canonical document is just plain wrong on this one, and I think all other documentation on the web on FE is basically derived from it ;)

Edited by DirtyHairy
  • Like 2

Share this post


Link to post
Share on other sites

I'd be interested in changing Stella to work in this fashion. While the current code works, I want to emulate what is actually happening, not what we think is happening.

  • Like 4

Share this post


Link to post
Share on other sites

Something else to add. I always felt that there was something fishy about the FE documentation too. While I understand what it is saying, I couldn't picture how the hardware was actually implementing it. And that should have been the first clue that docs are incorrect.

Share this post


Link to post
Share on other sites

I've now implemented this in Stella, in https://github.com/stella-emu/stella/commit/3a02c54b0aeaba5adaba1b6dc82b9aea75a5fbf4. The code is quite a bit simpler, and I also updated the docs (in the header file) to more properly explain what's going on. At some point we should send this info to K. Horton to have his documentation updated.

 

EDIT: I just looked at the most recent document from K.Horton, and in this version he does indeed delve a little further, and talk about the sequences of peeks and pokes that lead to latching onto a certain address. But he concentrates on watching for opcodes for JSR and RTS, while what should actually be watched is accesses to $01FE (regardless of the opcode that generates it). So he is part of the way to understanding, but not fully.

  • Like 2

Share this post


Link to post
Share on other sites

I've notified Kevin about our findings (kevtris here on AtariAge), pointing him to the patent application and the implementation in Stella. Hopefully he will update his documentation, so other emulator authors will have an easier time understanding this scheme.

  • Like 1

Share this post


Link to post
Share on other sites

hi,

 

just saw your replies (didn't get an automatic notification via atariage - can I enable this somehow ?!) and just wanted

to say that it's great to hear that you are changing Stella accordingly - I quite like the FE bank switching scheme myself.

It's elegant to implement in sw while at the same time simple to build in hw - even automatically initializes the bank during reset

since this triggers 1fe, too. If I ever write a <= 8K 2600 game it'll certainly be an FE one :)

 

Thomas

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...