Ultimate1MB - new preorder

[w1k]

i see that same :/

[wesmond]

How annoying... sorry to hear that Candle.

[fernando marrin]

when will we see the flasher ? Any Updates ?

 

need to modify that bios rom for Myide 2 ...

[atari8warez]

when will we see the flasher ? Any Updates ?

 

need to modify that bios rom for Myide 2 ...

 

You may try this Some people used it and reported good results. You can get it from here (make sure you read the disclaimer inside the read.me file)

Edited October 19, 2012 by atari8warez

[fernando marrin]

You may try this Some people used it and reported good results. You can get it from here (make sure you read the disclaimer inside the read.me file)

 

will try , thanxs

[SC1]

I am really sorry that I have missed last production batch. Will there be any further opportunity to buy U1MB?

 

(I have just registered to this forum...)

[atari8warez]

While testing FJC's AspeQt Folder Imaging fix today I found something with Ultimate1MB board. I am not sure if this is a bug or not so I wanted to see if anybody else has experienced this.

 

While a BASICXE cart is inserted to my 130XE which has the U1MB upgrade, if I boot into DOS2.5 (using SIO2PC and AspeQt), the computer boots with DOS 2.5, sets up a ramdisk @ D8 (U1MB is configured as having 1088K Rambo RAM), then goes to BASICXE as expected. However when I type DOS from BASICXE, instead of loading the DOS 2.5 menu the computer drops back to BASICXE editor after clearing the screen. If I boot the computer without BASICXE cart everything works as expected.

 

The DOS 2.5 I am using is an unmodifed (original) Atari DOS. Same thing happens if I boot my Atari with a 1050 with the original DOS 2.5 in the drive. Same behavior also occurs with Altirra when I try the same setup there.

 

EDIT: The problem only happens when U1MB is set to use 1088K - Rambo compatible RAM mode, in other mods DOS menu loads fine.

Edited October 23, 2012 by atari8warez

[Fox-1 / mnx]

Clashing 128KB/RamDiskdriver? Or is this too obvious?

 

When Atari introduced its 130XE this year, OSS upgraded BASIC XL for the new 128K machine. The result, BASIC XE, runs on all the XL computers but also adds commands to take advantage of the 130XE's expanded memory. The most important new command is XTEND. After you've typed or loaded a program into memory on the 130XE, you can use this command to move the program into the alternate 64K bank. At that point, your program and data space are separate—the former occupying the alternate 64K, and the latter occupying the main 48K (leaving about 35K free for data and strings). An optional third parameter for PEEK and POKE statements gives you access to any section of the 130XE's memory—the four extended banks of 16K or the main 48K RAM.

 

http://www.atarimagazines.com/compute/issue67/318_1_Reviews_BASIC_XE_For_Atari_XL_XE.php

[flashjazzcat]

Clashing 128KB/RamDiskdriver? Or is this too obvious?

 

Sounds a reasonable theory to me. BASIC XE will have wiped DUP.SYS off the RAMdisk.

[atari8warez]

Sounds a reasonable theory to me. BASIC XE will have wiped DUP.SYS off the RAMdisk.

 

Why doesn't it do the same thing with 320K, 512K or stock RAM (128K) then?

[atari8warez]

Clashing 128KB/RamDiskdriver? Or is this too obvious?

 

 

 

http://www.atarimaga...Atari_XL_XE.php

It's not really obvious to me as the same behaviour does not happen with other RAM upgrade mods available in U1MB.

 

Besides I didn't use the EXTEND command when this happened, so there was no access to extended memory.

Edited October 23, 2012 by atari8warez

[flashjazzcat]

PORTB mappings are different for the various upgrades, so it might be that the bank collision between BASIC XE and DUP.SYS only happens with certain sizes of extended RAM.

[atari8warez]

PORTB mappings are different for the various upgrades, so it might be that the bank collision between BASIC XE and DUP.SYS only happens with certain sizes of extended RAM.

 

That seems more reasonable or obvious (if i can say that) to me , so can we say that 1088K RAM mode is not compatible with Atari DOS?

 

Now having said that, here's a little twist to this story. If I use Hias's hi-speed patched DOS 2.5, the problem does not occur.

Edited October 23, 2012 by atari8warez

[flashjazzcat]

That seems more reasonable or obvious (if i can say that) to me , so can we say that 1088K RAM mode is not compatible with Atari DOS?

 

I'd say that we can say that - in 1088K mode - one of the banks BASIC XE uses happens to coincide with the first bank of the DOS 2.5 RAMdisk. If you don't use an application which happens to use those banks of extended RAM used by the RAMdisk, the RAMdisk should quite simply remain intact.

 

So - at the end of the day - it's the combination of the RAMdisk handler and BASIC XE that's at fault, and their ignorance of the existence of the 1MB upgrade.

[atari8warez]

I'd say that we can say that - in 1088K mode - one of the banks BASIC XE uses happens to coincide with the first bank of the DOS 2.5 RAMdisk. If you don't use an application which happens to use those banks of extended RAM used by the RAMdisk, the RAMdisk should quite simply remain intact.

 

So - at the end of the day - it's the combination of the RAMdisk handler and BASIC XE that's at fault, and their ignorance of the existence of the 1MB upgrade.

 

Jon, I can hardly blame DOS 2.5 ramdisk handler in this situation. How would one expect a ramdisk handler or BASICXE written in 198xs to be compatible with a hardware designed in 20xx. I really doubt that a RAMBO compatible 1088K ram expansion was available then, the only two 1088K upgrades of the day I know of is Peterson and Newell upgrades.. Correct me if I am wrong...

[flashjazzcat]

Jon, I can hardly blame DOS 2.5 ramdisk handler in this situation. How would one expect a ramdisk handler or BASICXE written in 198xs to be compatible with a hardware designed in 20xx. I really doubt that a RAMBO compatible 1088K ram expansion was available then, the only two 1088K upgrades of the day I know of is Peterson and Newell upgrades.. Correct me if I am wrong...

 

Ray - you've answered your own question. How can we expect BASIC XE and the DOS 2.5 RAMdisk handler to work together on a 1088K upgrade? Yet you wanted to know why those two pieces of software don't work on a 1088K upgrade. Now you know. By "fault" I don't mean "shortcoming" or "poor design"... excuse me. I merely mean it's not a "bug" in the 1088K implementation.

 

I'm trying to be as unambiguous as possible here, because you suggested that 1088K mode is not compatible with Atari DOS (correct me if I'm wrong), but this simply isn't the case.

[atari8warez]

Ray - you've answered your own question. How can we expect BASIC XE and the DOS 2.5 RAMdisk handler to work together on a 1088K upgrade? Yet you wanted to know why those two pieces of software don't work on a 1088K upgrade. Now you know. By "fault" I don't mean "shortcoming" or "poor design"... excuse me. I merely mean it's not a "bug" in the 1088K implementation.

 

I'm trying to be as unambiguous as possible here, because you suggested that 1088K mode is not compatible with Atari DOS (correct me if I'm wrong), but this simply isn't the case.

 

Ok, lets take a little breather and look into this problem a little more in detail.

 

I tried the same thing after I renamed RAMDISK.COM to RAMDISK.XXX on the DOS 2.5 disk, this time everything worked as expected. When I typed DOS from BASICXE the computer loaded it from the disk, not from ramdisk as there was no ramdisk setup. THEN i manually loaded RAMDISK.XXX from the DOS menu, the computer setup a ramdisk this time, I then dropped to BASICXE using the B. option from the menu, then from the BASICXE I typed DOS again and voila the DUP.SYS loaded successfuly from the ramdisk. When I drop back to BASICXE a second time, typing DIR "D8:*.*" shows me D8: contents

 

Contrast this to booting the disk with a ramdisk setup. Typing DOS from BASICXE does not load DUP.SYS, looking further into the problem by doing a DIR "D8:*.*" from BASICXE reveals a corrupted ramdisk VTOC (garbage printed as disk directory).

 

So it looks like there is a some sort of conflict with BASICXE/1088K/U1MB/DOS 2.5 combination. However whatever that conflict is it only happens when you boot the disk with ramdisk setup. Setting up a ramdisk AFTER the boot does not create the same problem.

 

I have no idea how to explain this behavior other than saying that something in the boot sequence screws things up.

 

EDIT: It seems to me that BASICXE (or something else) somehow corrupts the RAMDISK when its first initialized but not after the subsequent entry/exit.

Edited October 23, 2012 by atari8warez

[Fox-1 / mnx]

Scenario #1

DOS loads

RamDisk loads

DUP.SYS will be copied to RD

DOS exits to cartridge (BasicXE)

BXE claims (inits) the extra 128KB (using a PORT-B combo only the 1088KB expansion is using)

Problems when using RD (BXE claimed it)

 

Scenario #2

DOS loads

DOS exits to cartridge (BasicXE)

BXE claims 128KB

Load RamDisk by hand

Exit back to BXE (already claimed the 128KB so doesn't claim it again)

Probably leads to errors in BXE as soon the PORT-B combination is hit.

 

Does this sound reasonable?

[atari8warez]

Yes it sounds reasonable but not probable, why? because BASICXE follows Atari's guidelines in using the extended RAM as can be seen from the attachment photo. It is fully compatible with 130XE and even with upgrades which follow published guidelines.

 

Also your theory "Probably leads to errors in BXE as soon the PORT-B combination is hit." is not true either

. Had the theory been correct, as soon as I typed EXTEND in BASICXE the ramdisk should have been corrupted but this is not the case. (BASICXE does not touch extended RAM unless the program in memory is EXTENDED and even then it does not corrupt the ramdisk).

EDIT: I did also try using the extended ram from DOS (accessing the ram disk) to see if that corrupted anything in BXE and it did not.

 

BASICXE is also compatible with the 320K Rambo upgrade in the U1MB

 

The problem is when the computer is booted with a ramdisk already setup

 

So the problem does not seem to be BXE claiming available extended RAM but rather something else happening during the boot process. It may be something to do with U1MB Bios shuffling things in memory before giving the control to BXE. Of course this is also a theory like yours and I may be wrong, and i guess there is only one person who may be able to clear this up for us and you know who that is. (Clue: A person who prefers to ignore my messages about his upgrade)

Edited October 24, 2012 by atari8warez

[atari8warez]

On more addition to the above. RAMBO type RAM Upgrade is compatible with 130XE in CPU mode so it should be automatically compatible with BASICXE as can be seen here.

[Marius]

Hey a8w,

 

I think you are spending your time on the 'wrong' items. My experience is that there will always be incompatibilities between the different ram settings. I have software that does not work completely well in 320 and 1088 mode, but will work in 576K mode.

This 'things' already happened back in the day. There were these Compy Shop and Rambo differences from time to time.

 

It is a matter of accepting that. The more RAM the more bits of PORT B are occupied. The more of these bits are used by the ram expansion, the bigger the chance that things do not work as wanted or expected.

 

Atari only created an 128KB machine -> 130XE. Everything else is not standard, and might have issues.

 

I stick my Atari configuration most of the time to 64KB. Only when I absolutely need the memory upgrade I set the ultimate 1mb to 320K or higher. My only wish (and I still don't know that will ever happen) is that the Ultimate 1MB upgrade will also have a 100% true 130XE mode, but giving the atari just 64KB extra (128K total). If that will happen... I keep the Ultimate 1MB at 128KB in total by default.

 

Summarize: 1088K is an awful lot of memory for an original 64KB system. the more memory, the more complex the configuration (PORT B), the bigger the chance of trouble.

 

Anyway, the fault is not in the Ultimate 1MB, if that is what you are looking for.

[drac030]

The source of the problem, I'd guess, is BASIC XE. The interpreter, while starting up, probably needs to know if the extended memory is there. So it is likely, that it makes a test for that, and that test screws things up on 1088k. This may be why a ramdisk setup before BASIC XE initialization gets destroyed, and if setup after that - survives.

 

Now it only happens on 1088k, because - again, I'd guess - this one is the only extension which uses bit 1 of PORTB to switch banks. The same bit is used to enable and disable the BASIC interpreter in XL/XE. There is no conflict, when PORTB is used properly, but anyway, BASIC XE probably does not expect that a bit, which controls itself, also switches banks in certain circumstances.

 

The real cause is of course the fact, that 1088k is a hardware hack. A clever hack, but a hack, which changes the operation of PORTB bit 1 in a way that is not fully compatible with its operation on XL (where that bit controlled BASIC ROM unconditionally, and controlled nothing else besides that).

Edited October 24, 2012 by drac030

[atari8warez]

@Marius

 

I am not trying to blame anything really, I am just trying to find a reason for that behavior. I am well aware that there are incompatibilities between software and add-on hardware. The reason I said there is only one person who can probably correctly answer that question is because he is the one who designed the hardware and has intimate knowledge of the inner workings of that memory extension. I don't understand why it's always about assigning blame!... how about simply curiosity?.... simply trying to find an answer? why is everybody's ego so fragile around here?.... now I don't mean you of course but even you feel a need to defend somebody or some hardware when there are questions raised.. I just don't get this... really!!.

 

@Konrad

 

Konrad thank you for the explanation, in fact i also thought about that possibility, what I don't really quite understand is why there is no corruption of either the ramdisk or BXE after I loaded the ramdisk driver manually. That makes me believe BXE is aware of extended ram. I did tests with a BXE program which used almost all of extended memory and did not experience any corruption either on ramdisk or in the BXE work area. I tend to believe that BXE does not do a check of extended ram at initialization but only when a BXE program is extended with the EXTEND command...I also believe that BXE is aware of ram extensions greater than 64K (unlike ATARI DOS which always claims the first 64K of extended ram for a ramdisk) Anyway, I will look into it more when I have some time to spare for that and I'll do some reading about PORTB and bit 1.

 

Also the problem actually happens with both 512 and 1088K ram extensions. At first I thought only happened with 1088K but U1MB sometimes seems to do a warm boot instead of a cold boot when a new config is saved in the setup menu and "C" key is pressed. When that happens the computer boots with the old config, so I first thought I was running the test in 512K but it was actually 320K. In short only 320K upgrade works with BXE without that problem.

[Marius]

@a8w

Except for one line, my reply was almost the same as that of drac030. But I agree... I thought: oh no... a8w found another reason to pick on ultimate1mb. I believe you when you say it is just curiosity, but with the history of this thread in mind I really thought: oh no... is he still looking for some u1mb-bash. I moved too soon, but I hope this explains why I responded that way. I'm not so fragile, you can say whatever you want to me, and if you read all my comments about u1mb (in different threads) you'll find I have been a (impatient) pain too for candle... but I never got the feeling he was annoyed by that.

[Fox-1 / mnx]

If you really want to know the answer: get an 800XL and stuff 1088KB in it the old way, with RAMs.