flashjazzcat Posted January 12, 2012 Share Posted January 12, 2012 (edited) Heh - I wrote a 150,000 word novel on an XE in the 90s. Edited January 12, 2012 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Fox-1 / mnx Posted January 12, 2012 Share Posted January 12, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
DocRotCod Posted January 23, 2012 Share Posted January 23, 2012 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 Quote Link to comment Share on other sites More sharing options...
candle Posted January 23, 2012 Author Share Posted January 23, 2012 draco030 (author of firmware for ide+) was having similiar issues, and it went down to damaged/marginal ram chip on ide+ (and was the reason shipments were delayed back then - we had to check what is out of specs) Quote Link to comment Share on other sites More sharing options...
Marius Posted January 23, 2012 Share Posted January 23, 2012 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. Quote Link to comment Share on other sites More sharing options...
Marius Posted January 23, 2012 Share Posted January 23, 2012 (edited) I wrote about 29EE512 chip because I have 100% same issue with that Flash rom as with Ultimate 1MB. Edited January 23, 2012 by Marius1976 Quote Link to comment Share on other sites More sharing options...
candle Posted January 23, 2012 Author Share Posted January 23, 2012 and where exacly that chip would be? Quote Link to comment Share on other sites More sharing options...
Marius Posted January 23, 2012 Share Posted January 23, 2012 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. Quote Link to comment Share on other sites More sharing options...
candle Posted January 23, 2012 Author Share Posted January 23, 2012 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 Quote Link to comment Share on other sites More sharing options...
Marius Posted January 25, 2012 Share Posted January 25, 2012 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?) Quote Link to comment Share on other sites More sharing options...
candle Posted January 25, 2012 Author Share Posted January 25, 2012 (edited) 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 January 25, 2012 by candle Quote Link to comment Share on other sites More sharing options...
+Guitarman Posted January 25, 2012 Share Posted January 25, 2012 Forgot to post but I got my 2 Ultimate1MB boards last week. Thank you!!!!! Got a lot of projects to do now!! Quote Link to comment Share on other sites More sharing options...
Marius Posted January 26, 2012 Share Posted January 26, 2012 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). Quote Link to comment Share on other sites More sharing options...
Marius Posted January 30, 2012 Share Posted January 30, 2012 Is there any news yet about the OS/Basic flasher? Quote Link to comment Share on other sites More sharing options...
candle Posted January 30, 2012 Author Share Posted January 30, 2012 Hi Marius it was ready the day i've replied, but current version requires some work would you like to beta test it? but before we proceed, will you have any means of reprogramming flash chip outside atari if something goes wrong? Quote Link to comment Share on other sites More sharing options...
Marius Posted January 30, 2012 Share Posted January 30, 2012 Hi candle, If you tell me what I need to reprogram flash chip in case something goes wrong, I'll get myself that. Yes I would like to beta test it. I really am very interested in the feature of U1MB. Thanks a lot! Quote Link to comment Share on other sites More sharing options...
candle Posted January 30, 2012 Author Share Posted January 30, 2012 any eprom programmer, or a sic-cart with plcc32 adapter Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 30, 2012 Share Posted January 30, 2012 Sebastian: how much ROM space could realistically be harnessed by the GUI, assuming it was living alongside SpartaDOS X? Ultimate 1MB - given it brings both RAM and flash ROM to the table - is a fairly enticing proposition for the GUI. 1 Quote Link to comment Share on other sites More sharing options...
candle Posted January 30, 2012 Author Share Posted January 30, 2012 with some software provisions? possibly more than 128k, but this is long shot, i'll check when i'm off the hook Quote Link to comment Share on other sites More sharing options...
Marius Posted January 30, 2012 Share Posted January 30, 2012 any eprom programmer, or a sic-cart with plcc32 adapter Ah yes. I got that kind of stuff indeed. So please count me in for beta testing! Thanks M. Quote Link to comment Share on other sites More sharing options...
candle Posted January 30, 2012 Author Share Posted January 30, 2012 ok Marius, expect something from me around 22-23:00 CET it will be up hill, but we will get there i'll add some automation later to this Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 30, 2012 Share Posted January 30, 2012 with some software provisions? possibly more than 128k, but this is long shot, i'll check when i'm off the hook More than enough. 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted January 30, 2012 Share Posted January 30, 2012 with some software provisions? possibly more than 128k, but this is long shot, i'll check when i'm off the hook More than enough. I am REALLY liking the sound of this Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted January 31, 2012 Share Posted January 31, 2012 any eprom programmer, or a sic-cart with plcc32 adapter Hmmm, looks like my Willem supports the plcc32, what is the part number? I might be able to help test too Jay Quote Link to comment Share on other sites More sharing options...
candle Posted January 31, 2012 Author Share Posted January 31, 2012 on ultimate? its a29040b as far as i remember Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.