Jump to content

Ultimate Cart (SD multicart) - Technical thread

Recommended Posts

I didn't mean to imply that the proposed fix is incorrect. 


I only meant to add that my system behaved differently, for whatever reason. If the patch improves the functionality of my machine then I'm all for it.


Could this issue affect basic programs loaded from disk? The disk drive is rarely something I play around with since ours never seemed to work when I was younger, but I have a backlog of titles I'd like to look at.


Ah but his firmware fix is the forgotten thing and how it's done, the hardware fix is definitely needed as this sort of thing replicated through out time and devices that use the cartridge/pbi that need the timing. A number of people put switches in to allow using some older devices/cartridges to work and then use the switch to help with carts and newer item that use the phi timings instead... long story short, if all devices took both approaches into account, the systems would be rock solid. If you dig deep enough you will probably find discussions or which carts had issues with the 800/400 and vice versa with the XL/XE. Precisely for both reasons.

Share this post

Link to post
Share on other sites

I'd do the mod with the switch, and update firmware when available.


When you say drive... do you mean SIO drive, pbi drive, etc.?

Share this post

Link to post
Share on other sites

I have a 48k 800 and an Ultimate Cart SD running whatever firmware was current last November.
When I run "PRINT FRE(0)", I get 37899, despite not having the fix you propose.

37899, and not 37902?

Whether the 6502 can still write properly to the affected memory area depends on the value the FPGA places on the data bus during bus contention.

Each "1" bit coming from the FPGA can be pulled down to "0" by the NMOS 6502. However, a "0" bit will most likely stay "0", no matter what the 6502 places on the bus.


Fact is that the Ultimate Cartridge relies on a XL/XE MMU behavior which the original 800 design does not provide.


This can be easily verified by checking the Atari 800 schematics - the /S4, /S5 outputs from the 74LS42 do NOT get disabled by RD4 or RD5, they are ALWAYS active. But the current FPGA firmware always drives the data bus when either /S4 or /S5 is pulled low.


So, no matter if it has worked "by accident" for you, this is an issue which needs to be fixed.


Maybe you get those last 3 bytes back by trying my firmware code:



Edited by Vigo

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.

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.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...