Jump to content
IGNORED

Ultimate1MB preorder starts


candle

Chear or Pro?  

128 members have voted

  1. 1. Should the PCB be PRO?


  • Please sign in to vote in this poll.

Recommended Posts

The thing is, if you're producing anything substantial on the real machine, you tend to assemble to a file rather than RAM.

 

With MAC65 I assemble to RamDisk by default. I use Sparta-Dos with some batch files. During programming my source is always named Q.ASM where my compiled version is named X.COM. So assembling is done to X.COM on the RamDisk. When at the Sparta-Dos Commandline I just run file named R.BAT to run the code. This batch file loads all parts I need, somethnig like:

 

LOAD D9:INIT.COM

LOAD D9:SCREEN.COM

LOAD D9:PLAYER.COM

LOAD D9:MSX.COM

LOAD D9:PIC.COM

D9:X.COM

RUN 2400

 

Reloading all data at each run makes sure it's "fresh" (not overwritten during coding/assembling) and takes about no time as it's loaded from RamDisk using JKP's RamJet. Rebooting when the system completely hangs is also no problem as the BlackBox has a cold-start feature and when restarted the RamDisk will be set-up without formating so everything is still there. In case it's not there it's just a matter a copying all data (which usually means COPY *.COM D9: in my case as it's all in 1 directory) to the RD again.

 

Returning to the assembler is just a matter of running -D9:M.BAT which does D9:MAC65.COM LOAD#D9:Q.ASM and MAC65 will be loaded, together with the source, in virtually no time.

 

The only thing to keep in mind is that I'll have to save my source code to the HDD every now and then.

 

At last all parts will be linked together with SuperPacker when the time for a final version is there.

 

When I'll have to do some programming for the BBS it works a bit different as this code only runs on the BBS itself. In this case I assemble to an old fashion 1050 disk drive (Speedy DS HighSpeed) and since I use a "2-rechner-interface" I can access that same floppy drive on both my 8-bits (save with the coding 130XE, load on the BBS 130XE). Of course one can use a virtual SIO2PC disk drive too but since each 130XE has it's own dedicated SIO2PC connection this is getting a bit complicated in my case. Assembling to floppy will just do because the BBS is text based so things like DLI's, VBI's and/or other time-critical code won't be used in most cases anyways so there usually isn't much to debug.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Hope someone here can help. I've got a strange issue with my Ultimate. When using by itsself and no other devices/mods present, it works fine. If I connect my IDE+ it APPEARS to work fine but when I start doing directory listings and whatnot I get garbled results part of the time. I can re run the directory and sometimes it will be ok other times there will be additional garbling in the listing. If I remove the Ultimate and plug in the MMU and OS again and JUST use the IDE+ it works fine.

 

Any ideas? Can someone else with this setup test this scenario?

 

Thanks

Link to comment
Share on other sites

I have probably described same issue with BlackBox. I have the same thing when I use a (fast) Flash Chip as EPROM in stead of regular EPROM.

 

When I Install a 29EE512 EEPROM in my Atari 800XL (right rewired ofcourse), and I Hook UP the BlackBox... I see all kind of unwanted and unexpected things on my screen.

 

My idea is that these modern chips are too fast for little atari. It's exact the same problem when you upgrade your atari with DRAM chips that are too fast. In school you learn that 'too fast' is not possible. That is wrong. For little atari 'a bit slower' is good. The faster the chip, the more sensitive for flaws in the atari-design.

 

I think THAT is also the issue here.

Pretty sure I mean.

Link to comment
Share on other sites

and where exacly that chip would be?

 

For some reasons I don't understand we have a lot of misunderstandings lately.

 

I say that I have SAME problems using an Atari 800XL where I replaced the OS with a 29EE512 Flash Rom. This is (ofcourse) an atari without Ultimate 1MB.

 

I experience 100% same issues here:

 

Atari + Flash ROM (29EE512 chip) + BlackBox

 

or

 

Atari + Ultimate1MB + BlackBox

 

or what a few posts above mine is describe

 

Atari + Ultimate1MB + IDE+ interface

 

My conclusion with the Flash Eprom was already month's ago that this chips is (far) too fast for the Atari.

I explain in my post above that in school we 'learn' that 'too fast' does not exist, but on little Atari it is true. Also with too fast DRAM chips.

 

I write all this, because I think that Ultimate1MB is build upon the same fast components, which MIGHT be too fast for little atari. Especially as soon as there is more bus load (because of PBI interfaces). The lag that occurs on let's say Ph2 line is interferring too much, and there you go: problems.

 

I'm ok with it. On my Ultimate 1MB Atari I simply do stick to SIO based storage. That works great too.

But I was writing all this, to make it easier to search in a certain direction.

Link to comment
Share on other sites

Marius, fast components driving slow chips is a problem

fast components driving other fast components is not a problem at all

i've used 29ee512 in the past as rom replacemnent without any issues

perhaps your part is marginal? could you get another one and re-check?

if there are some spikes on chip select lines - fast part might kick in, but it should kick out fast enough not to cause any troubles

there are some more constrains, but if you have nice slopes on your signals (not too steep, not too slow) everything should be ok

as for phi2 - ide+ uses rc circuitry to push back falling edge of phi2 about 70-80ns - this is late enough for cpu to have all data ready on the bus, but still early enough to compensate for any skew that might get introduced by marginal buffers, or bus load/cabling

the same approach is used in karin-maxi drive, side, and number of Hias/MegaHz creations

bottom line - nothing that screwes phi2 should not influence ide+ reliablity - but something does

Link to comment
Share on other sites

bottom line - nothing that screwes phi2 should not influence ide+ reliablity - but something does

 

The big question is.... is it really the reliability of ide+ that is influenced or is it something inside Atari that is disturbed. I am not a technical miracle, but there is some sync-trouble around chip enable / output enable on the OS ROM. This goes wrong rather soon. There is a certain bandwith in between things run fine, but as soon things walk out of hand the whole Atari is acting weird. The user sees this in strange behavior in the screen output, but that is the visible part. RAM in Atari get easily corrupted.

 

I tried several 29EE512 and also a 29ee010. All both trouble. As long as nothing is connected to the PBI everything runs fine. But as soon as I hook up the BB to the PBI: trouble! With a regular EPROM or the default Atari OS ROM everything works fine. Using a longer Black Box cable had effect too. It's sensitive. I don't like that.

 

It reminds me of the time I had a Klaus Bucholz 256KB Atari 800XL. What a disaster. It simply can not work right. Too much lag on the multiplexer circuit. It works great as long as you run a 256KB demo. But as soon as you want to use your ramdisk a bit longer than 1 hour, you can count on it that you get corrupted ram.

 

Hias told me that his SRAM upgrade works with Ph0 in stead of Ph2. Wouldn't that be a great solution for Ultimate1MB too, or isn't that possible (or did I understand him wrong?)

Link to comment
Share on other sites

you can connect ultimate to phi0 instead of phi2 and see if there is any diffrence

vbxe synces with phi1 for that reason (because of phi2 problems)

but as i stated - i did my homework, and i am sure ultimate1mb is reliable

 

most important thing is, that in ultimate, and in original MMU OS chip rom decoder is ASYNCHRONOUS - it doesn't depend on any clock signal

Edited by candle
Link to comment
Share on other sites

but as i stated - i did my homework, and i am sure ultimate1mb is reliable

 

I agree with you. I'm also sure about that.

 

It is the design of the atari itself I was evaluating. That's why I brought up the problems with the FLASH rom. Even with the Flash Rom I have similar issues like Ultimate 1MB. And I still am sure those FlashRoms are ok too.

 

The Atari is sensitive on this point, and old...

 

For memory upgrades with DRAM there is a fix for this (building an extra refresh circuit). I'm wondering if such a solution could be possible for issues like these too.

 

That would not be a fix to Ultimate 1MB but an overall Atari Fix. suitable for several problems (which are caused by the same issue).

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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