Jump to content
electrotrains

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
Posted (edited)

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:

 

https://ufile.io/34bi949t

Edited by Vigo
  • Like 2

Share this post


Link to post
Share on other sites

 

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

 

https://ufile.io/34bi949t

 

I am finally able to get around to trying your firmware--but the link no longer works. Can you please re-upload this? I can see if it recovers my missing bytes.

Share this post


Link to post
Share on other sites
Posted (edited)
On 6/13/2019 at 10:10 AM, spspspsp said:

 

I am finally able to get around to trying your firmware--but the link no longer works. Can you please re-upload this? I can see if it recovers my missing bytes.

Here you go again:

 

https://www.filehosting.org/file/details/807882/Max10_SD_fixed_bus_contention.zip

 

Actually, I am wondering why this hasn't already made it into the official firmware update, since the problem I have described should be quite apparent for anyone, who can read the original Atari 800 schematics:

 

http://www.jsobola.atari8.info/dereatari/literatdere/400_800sm.pdf

 

Page 64. S4 and S5 on J108 & J109 are ALWAYS selected by the 74LS42 (Z101). The OR gate (Z102) is only masking the signals for the RAM cartridges.

 

This fix is basically a no-brainer. But right now, without fixing this issue, the Ultimate Cart should not be used in an original Atari 800.

 

Best regards,

 

Vigo

Edited by Vigo
  • Like 2

Share this post


Link to post
Share on other sites

I don't think the firmware author is around much and there isn't any active development going on.

 

Share this post


Link to post
Share on other sites

Hi,

I can't program Altera,

I don't know if it's a matter of cheap USB Blaster programmer clone or assembly of the cartridge itself:

 

The programmer is visible in the system:

$ dmesg -r

<6>[14848.078157] usb 1-1.3: new full-speed USB device number 23 using ehci-pci
<6>[14848.186946] usb 1-1.3: New USB device found, idVendor=09fb, idProduct=6001
<6>[14848.186949] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
<6>[14848.186950] usb 1-1.3: Product: USB-Blaster(Altera)
<6>[14848.186951] usb 1-1.3: Manufacturer: Altera
<6>[14848.186952] usb 1-1.3: SerialNumber: 8D7B43845056

 

Chip is detected:

$ ./jtagconfig -d
1) USB-Blaster(Altera) [1-1.3]
  031820DD   10M08SA(.|ES)/10M08SC (IR=10)

  Captured DR after reset = (031820DD) [32]
  Captured IR after reset = (151) [10]
  Captured Bypass after reset = (0) [1]
  Captured Bypass chain = (0) [1]
  JTAG clock speed 6 MHz
$ ./bin/quartus_pgm --auto
Info: *******************************************************************
Info: Running Quartus Prime Programmer
    Info: Version 18.1.0 Build 625 09/12/2018 SJ Standard Edition
    Info: Copyright (C) 2018  Intel Corporation. All rights reserved. 

[.....]
    Info: Processing started: Tue Jun  4 00:26:08 2019
Info: Command: quartus_pgm --auto
Info (213045): Using programming cable "USB-Blaster(Altera) [1-1.3]"
1) USB-Blaster(Altera) [1-1.3]
  031820DD   10M08SA(.|ES)/10M08SC

Info: Quartus Prime Programmer was successful. 0 errors, 0 warnings
    Info: Peak virtual memory: 425 megabytes
    Info: Processing ended: Tue Jun  4 00:26:08 2019
    Info: Elapsed time: 00:00:00
    Info: Total CPU time (on all processors): 00:00:00

 

But the programming process always ends with the following error:

 

$./bin/quartus_pgm -m jtag -o "p;/home/johny/UltimateCart/Programming Files/New Firmware (XEX loading)/10M08SAE144C8G.pof"
Info: *******************************************************************
Info: Running Quartus Prime Programmer
    Info: Version 18.1.0 Build 625 09/12/2018 SJ Standard Edition
[....]
Info: Processing started: Tue Jun  4 00:30:10 2019
Info: Command: quartus_pgm -m jtag -o "p;/home/johny/UltimateCart/Programming Files/New Firmware (XEX loading)/10M08SAE144C8G.pof"
Info (213045): Using programming cable "USB-Blaster(Altera) [1-1.3]"
Info (213011): Using programming file /home/johny/UltimateCart/Programming Files/New Firmware (XEX loading)/10M08SAE144C8G.pof with checksum 0x01D3FF3A for device [email protected]
Info (209060): Started Programmer operation at Tue Jun  4 00:30:10 2019
Info (209017): Device 1 contains JTAG ID code 0x031820DD
Info (209060): Started Programmer operation at Tue Jun  4 00:30:10 2019
Info (209016): Configuring device index 1
Info (209017): Device 1 contains JTAG ID code 0x031820DD
Info (209007): Configuration succeeded -- 1 device(s) configured
Info (209011): Successfully performed operation(s)
Info (209061): Ended Programmer operation at Tue Jun  4 00:30:13 2019
Error (209012): Operation failed
Info (209061): Ended Programmer operation at Tue Jun  4 00:30:53 2019
Error: Quartus Prime Programmer was unsuccessful. 1 error, 0 warnings
    Error: Peak virtual memory: 449 megabytes
    Error: Processing ended: Tue Jun  4 00:30:53 2019
    Error: Elapsed time: 00:00:43
    Error: Total CPU time (on all processors): 00:00:00

 

Any suggestions?

 

 

 

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
On 6/25/2019 at 3:22 AM, Vigo said:

Here you go again:

...

Vigo

 

Vigo,

 

Thank you for re-uploading your firmware.

 

My system now shows 37902 bytes of memory free.

  • Like 2

Share this post


Link to post
Share on other sites
On 6/24/2019 at 11:22 AM, Vigo said:

Actually, I am wondering why this hasn't already made it into the official firmware update, since the problem I have described should be quite apparent for anyone, who can read the original Atari 800 schematics

Do you have a github account? Make a pull request with your suggested change and the author will be notified to review and merge if he agrees.

 

The same problem occurs with UNO Cart in the 400/800, but the required code changes are scattered throughout. UNO Cart works with an Incognito 800 since LS42 is replaced and S4/S5 behavior is changed.

Share this post


Link to post
Share on other sites
8 hours ago, tane said:

ATR reading would be the better improvement.

Not for folks who use 400’s and 800’s.

  • Like 1

Share this post


Link to post
Share on other sites

Mmm... of course the unusual 400-800 user needs a starting point. Is there a technical reason why an atr does not work on those?

Share this post


Link to post
Share on other sites

No but the improvement you think atr reading would be better than, is "Make the Ultimate Cart work on 400/800" so yes, I think 400/800 users would rather have that fix.

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

The title of this topic is not "Make the Ultimate Cart work on 400/800", it's for all devices. So ATR reading would be the better compatibility improvement for the Ultimate Cart.

 

Being that Uno Cart supports ATRs, it should be straightforward to upgrade the Ultimate firmware. Unfortunately Uno Cart is too limited with its features, and at the same time the Ultimate is too expensive for a cart.

 

 

Edited by tane

Share this post


Link to post
Share on other sites
1 hour ago, tane said:

The title of this topic is not "Make the Ultimate Cart work on 400/800", it's for all devices. So ATR reading would be the better compatibility improvement for the Ultimate Cart.

 

Being that Uno Cart supports ATRs, it should be straightforward to upgrade the Ultimate firmware. Unfortunately Uno Cart is too limited with its features, and at the same time the Ultimate is too expensive for a cart.

 

 

The discussion you barged in on, immediately after several posts in a row about the same issue - which was about fixing 400/800 CAR compatibility - not anything to do with ATRs.

  • Like 1

Share this post


Link to post
Share on other sites

 

1 hour ago, tane said:

The title of this topic is not "Make the Ultimate Cart work on 400/800", it's for all devices.

 

Two of those devices cannot use the Ultimate cart at all, making it work for those people is a bigger improvement than adding a feature for people already using it. 

 

1 hour ago, tane said:

Being that Uno Cart supports ATRs, it should be straightforward to upgrade the Ultimate firmware.

 

I await your pull request with bated breath!

 

 

1 hour ago, tane said:

Unfortunately Uno Cart is too limited with its features, and at the same time the Ultimate is too expensive for a cart.

Sounds like you need an AVG cart, that also loads ATR's and it's cheaper.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

I've been browsing the source code of the UC firmware and I've just so confused! 

 

In atari_rom.vhd, there's this bit where the supported cart types are listed:

	constant CART_TYPE_BOOT	: integer := 0;
	constant CART_TYPE_8K	: integer := 1;
	constant CART_TYPE_16K	: integer := 2;
	constant CART_TYPE_ATARIMAX_1MBIT : integer := 3;
	constant CART_TYPE_ATARIMAX_8MBIT : integer := 4;
	constant CART_TYPE_XEGS_32K : integer := 5;
	constant CART_TYPE_XEGS_64K : integer := 6;
	constant CART_TYPE_XEGS_128K : integer := 7;
	constant CART_TYPE_XEGS_256K : integer := 8;
	constant CART_TYPE_XEGS_512K : integer := 9;
	constant CART_TYPE_XEGS_1024K : integer := 10;
	constant CART_TYPE_SW_XEGS_32K : integer := 11;
	constant CART_TYPE_SW_XEGS_64K : integer := 12;
	constant CART_TYPE_SW_XEGS_128K : integer := 13;
	constant CART_TYPE_SW_XEGS_256K : integer := 14;
	constant CART_TYPE_SW_XEGS_512K : integer := 15;
	constant CART_TYPE_SW_XEGS_1024K : integer := 16;
	constant CART_TYPE_MEGACART_16K : integer := 17;
	constant CART_TYPE_MEGACART_32K : integer := 18;
	constant CART_TYPE_MEGACART_64K : integer := 19;
	constant CART_TYPE_MEGACART_128K : integer := 20;
	constant CART_TYPE_MEGACART_256K : integer := 21;
	constant CART_TYPE_MEGACART_512K : integer := 22;
	constant CART_TYPE_MEGACART_1024K : integer := 23;
	constant CART_TYPE_BOUNTY_BOB : integer := 24;
	constant CART_TYPE_WILLIAMS_64K : integer := 25;
	constant CART_TYPE_OSS_16K_034M	: integer :=  26;
	constant CART_TYPE_OSS_16K_043M : integer := 27;
	constant CART_TYPE_OSS_16K_TYPE_B : integer := 28;
	constant CART_TYPE_OSS_8K : integer := 29;
	constant CART_TYPE_SIC : integer := 30;
	constant CART_TYPE_SDX_64K : integer := 31;
	constant CART_TYPE_DIAMOND_64K : integer := 32;
	constant CART_TYPE_EXPRESS_64K : integer := 33;
	constant CART_TYPE_SDX_128K : integer := 34;
	constant CART_TYPE_BLIZZARD_16K : integer := 35;
	constant CART_TYPE_XEX : integer := 254;
	constant CART_TYPE_NONE : integer := 255;

And this bit where the cart types are initialised:

					if (new_cart_type = CART_TYPE_NONE or new_cart_type = CART_TYPE_XEX) then
						high_bank_enabled <= '0';
						file_offset <= (others => '0');
					elsif (new_cart_type = CART_TYPE_16K or new_cart_type = CART_TYPE_BLIZZARD_16K) then
						low_bank_enabled <= '1';
					elsif (new_cart_type = CART_TYPE_ATARIMAX_8MBIT) then
						bank_out <= "1111111";
					elsif (new_cart_type >= CART_TYPE_XEGS_32K and new_cart_type <= CART_TYPE_XEGS_1024K) then
						low_bank_enabled <= '1';
					elsif (new_cart_type >= CART_TYPE_SW_XEGS_32K and new_cart_type <= CART_TYPE_SW_XEGS_1024K) then
						low_bank_enabled <= '1';
					elsif (new_cart_type >= CART_TYPE_MEGACART_16K and new_cart_type <= CART_TYPE_MEGACART_1024K) then
						low_bank_enabled <= '1';
					elsif (new_cart_type = CART_TYPE_BOUNTY_BOB) then
						low_bank_enabled <= '1';
						bounty_bob_bank8 <= "00";
						bounty_bob_bank9 <= "00";
					elsif (new_cart_type = CART_TYPE_OSS_16K_TYPE_B or new_cart_type = CART_TYPE_OSS_8K) then
						oss_bank <= "01";
					elsif (new_cart_type = CART_TYPE_OSS_16K_034M or new_cart_type = CART_TYPE_OSS_16K_043M) then
						oss_bank <= "00";
					elsif (new_cart_type = CART_TYPE_SIC) then
						low_bank_enabled <= '1';
						sic_d500_byte <= (others => '0');
					end if;
					cart_type <= new_cart_type;

But I can't see where the cart type is mapped to the internal value. eg, An Atarimax 8Mb cart is a type 42 cart, but in the UC software it's a 4.

 

I can't find where one value is mapped to the other, what am I missing? 

 

 

EDIT: Turns out I was missing ultimate.c in software/sdcard...

Edited by Mr Robot
Answering my own question

Share this post


Link to post
Share on other sites
 
Vigo,
 
Thank you for re-uploading your firmware.
 
My system now shows 37902 bytes of memory free.


My ATARI 800 also shows the correct bytes free, didn’t have to update anything.

Share this post


Link to post
Share on other sites
On 6/24/2019 at 12:02 PM, tane said:

Uploading files, so as not to get lost:

 

Ultimate Cart Fixed Firmware for Atari 800:  Max10_SD_fixed_bus_contention.7z 93.73 kB · 16 downloads

 

ATARI 400/800 Service Manual:  400_800sm.pdf 5.38 MB · 11 downloads

I downloaded this and will test it out.  

 

Feel free to tag me, so I see these threads.  I am not the one that developed the firmware ( @flashjazzcat & @electrotrains were), but I am the one selling some of them (not all, definitely) so I can try to at least move the ball where it needs to be.

  • Like 2

Share this post


Link to post
Share on other sites
On 6/29/2019 at 9:07 AM, tane said:

Mmm... of course the unusual 400-800 user needs a starting point. Is there a technical reason why an atr does not work on those?

I believe because the 'hack' is to copy the ROM OS to RAM under the OS on XL's and XE's, then patch SIOV to redirect to a 'virtual disk' on the cartridge.  The 400/800 have no RAM under the ROM, so that method won't work. Even on XL/XE's, programes/games that make use of RAM under the OS will not work because it would corrupt the RAM OS.

Share this post


Link to post
Share on other sites

I get 37902 free on my Atari 800 as well... Is that how it should be? Any need to reflash the Ultimate Cart?

Share this post


Link to post
Share on other sites
19 minutes ago, Laner said:

I get 37902 free on my Atari 800 as well... Is that how it should be? Any need to reflash the Ultimate Cart?

That's the correct free RAM under Atari BASIC on a 48k machine.

Share this post


Link to post
Share on other sites

I'd like to build one of these, however the files on Github don't seem to agree with OSHPark.  Also tried importing the eagle files into Kicad, but also got errors.  Anyone else have these issues?  I haven't tried the Santosp version yet though.

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...