Jump to content

Recommended Posts

From my experience modifying a PILOT XEX to work on XL/XE - the 8KB ROM dump gets loaded into the cartridge memory area (40-48K mark), but first a preliminary step must be taken to relocate MEMTOP below that memory area (40K mark), and then re-open the E: handler.

 

On top of that, due to bugs in the 400/800 OSA/B, the E: handler will sometimes clobber memory above MEMTOP when shifting/inserting/deleting screen lines, so you set MEMTOP another 4KB below that (36K mark) to protect the cartridge code....

 

This leaves 4KB less usable RAM than if you had the real ROM cartridge (or something similar, like the pill that disables writes to those regions of memory). An XL/XE only version could regain the 4KB.. A creative loader could conditionally check which OS is present for universal compatibility..

Share this post


Link to post
Share on other sites

Hi!

 

From my experience modifying a PILOT XEX to work on XL/XE - the 8KB ROM dump gets loaded into the cartridge memory area (40-48K mark), but first a preliminary step must be taken to relocate MEMTOP below that memory area (40K mark), and then re-open the E: handler.

 

On top of that, due to bugs in the 400/800 OSA/B, the E: handler will sometimes clobber memory above MEMTOP when shifting/inserting/deleting screen lines, so you set MEMTOP another 4KB below that (36K mark) to protect the cartridge code....

 

This leaves 4KB less usable RAM than if you had the real ROM cartridge (or something similar, like the pill that disables writes to those regions of memory). An XL/XE only version could regain the 4KB.. A creative loader could conditionally check which OS is present for universal compatibility..

You can use this loader, based on the AltirraBASIC one and modified to load "any" ROM. Just name your ROM file "rom.bin" and assemble with MADS. The loader checks if printing a "CLR" character erases part of the top memory, and in this case lowers the RAMTOP 4k.

 

Also, as an example, I included the converted Assembler Editor RevA and RevB, this gives you 4K more in the XL os.

romload.s

AssemblerEditor-RevA.xex

AssemblerEditor-RevB.xex

  • Like 5

Share this post


Link to post
Share on other sites

You can use this loader, based on the AltirraBASIC one and modified to load "any" ROM. Just name your ROM file "rom.bin" and assemble with MADS. The loader checks if printing a "CLR" character erases part of the top memory, and in this case lowers the RAMTOP 4k

Wow, of course this has been thought of before. :) Thanks, that's great! I'll definitely take a look at this.

Share this post


Link to post
Share on other sites

Since it came up, my history of cartridge images. If you<not a specific person> recall there was a program called COPYCART.OBJ<CARTCOPY.OBJ?> that people used with an 800 before the XL series came out. There were also a lot of people that trashed the XL series because they wouldn't run earlier software. Truth was, they were trying to run the dozens of carts that were copied by CARTCOPY. So way back in the Compuserve and BBS days I disassembled CARTCOPY USR and found it was loading a clr screen character into the A register and making an illegal jump to $F3F6<?>. I fixed this every way possible like adding the question 'Is this going to be run on an 800 or xl?", rewriting the routine such that it would do the jump legally through CIO channel 0, and a program that would patch the offending binaries to make them run on anything. I guess a lot of stuff like the Yogi archive never got patched so there are still a lot of offending programs out there.

 

I seem to recall there were at least two cart copying programs. One you needed to stick a pencil in the 800 power interlock to leave the cartridge door open and you would just stick a pencil in to keep the power on. The other was a BASIC program and you would stick the cartridge to be copied in right cart slot.

 

I'm pretty sure I actually trapped reset on a version I made for myself so I could recover from my many programming mistakes w/o having to reload the cart.

  • Like 3

Share this post


Link to post
Share on other sites

Since it came up, my history of cartridge images. If you<not a specific person> recall there was a program called COPYCART.OBJ<CARTCOPY.OBJ?> that people used with an 800 before the XL series came out. There were also a lot of people that trashed the XL series because they wouldn't run earlier software. Truth was, they were trying to run the dozens of carts that were copied by CARTCOPY. So way back in the Compuserve and BBS days I disassembled CARTCOPY USR and found it was loading a clr screen character into the A register and making an illegal jump to $F3F6<?>. I fixed this every way possible like adding the question 'Is this going to be run on an 800 or xl?", rewriting the routine such that it would do the jump legally through CIO channel 0, and a program that would patch the offending binaries to make them run on anything. I guess a lot of stuff like the Yogi archive never got patched so there are still a lot of offending programs out there.

 

I seem to recall there were at least two cart copying programs. One you needed to stick a pencil in the 800 power interlock to leave the cartridge door open and you would just stick a pencil in to keep the power on. The other was a BASIC program and you would stick the cartridge to be copied in right cart slot.

 

I'm pretty sure I actually trapped reset on a version I made for myself so I could recover from my many programming mistakes w/o having to reload the cart.

this comes back to the point that most of what doesn't run could and quite easily, point in fact this piece of information still gets overlooked today... I suggest this be propagated through all the material at hand, as well as scans of books and guides as well as current endeavors to document how things should be be done. ie technical manuals, instructional material, and references.

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

This would seem a very rare thing and quick searches of main download areas (e.g. AtariOnline.pl) will hold the multiple variants of one title so finding one that works-for-you shouldn't be a big deal, e.g. people are wanting to play something and don't necessarily posses the skill-set to fix it themselves. Making a patched version as a 'one-fits-all' (as we have recently with Designers Pencil / Pilot / Forth etc) are straight-forward enough but simply add another option for people to download and might not be available at all sites, i.e. it isn't going to replace the other variants out there already. Along the same lines would be the making / fixing of existing programs to detect and use the right colours and timings between NTSC and PAL - nice to have but if a PAL and NTSC version already existing separately then use them.

Edited by Wrathchild

Share this post


Link to post
Share on other sites

The problem becomes what of the six versions posted works for the most people. Why after all theses years are will still sorting through 5 of this 4 of that to find the one that runs. At this point we still don't know what has or hasn't been fixed up for whatever problem it had and in a normal ready to go compilation. As time progresses the bad pennies keep overtaking the good stuff and we are back to trying to figure out why. Then we dig up the old answers after much frustration only to do some fixes and do it all over again.

 

Wouldn't it just be good to sort it out. You've done the work, why not have it stick and be done across the board.

Share this post


Link to post
Share on other sites

Short answer I'd say is time and resources, and like you point out a repetition of things that have gone before. Also, technologies evolve (covered later)

 

But there has been a proliferation of 'collections' as people have built up their own now that IDE/CF devices have become more commonplace.

New people have come onto places like AA and asked how to get started and so we have many disparate threads with posts of large collections.

 

The like of places such as AtariMania, AtariOnline and Fandal generally hold the back catalogue but each ring-fence the sort of things they hold, e.g. AtariMania strives to hold more 'pure' sources, not the variants.
Users like CharlieChapin seem to have their own, well indexed, collections and can offer up a set of 'programs of this genre' at the drop of a hat.

Users like Starwindz and Mclaneinc had invested their time in compiling the best game pack and there are other efforts that should all be applauded.

Other sites such as AtariMax hold cartridge images and the disk files for blowing them.

 

In regards to the technologies, these (fantastically!) move on and so as an example we have Farb's great set of ATX to ATR conversions but we've entered a time where SDrive-MAX and others can mount them so do we discard all that other work and only use the 'original' sources. For me the answer is no, we need to retain the 'history' of why the variants were made.

 

What I don't see happening (though would like to of course) is 'another' definitive source being established to bring everything into a central repository where each title is vetted and filed well but I would prefer to see the likes of AtariMania (my own personal goto-place if I want to find an image) encompass it all and expand the search criteria with things such as minimal memory requirement and cartridge type/size. Also, do those other sites then become redundant? As another thread highlighted where the TOSEC naming convention came under fire. So many other points like that to consider.

So overall I'm just resigned that things will just go on as they are ;)

Edited by Wrathchild
  • Like 1

Share this post


Link to post
Share on other sites

Hi!

 

The problem becomes what of the six versions posted works for the most people. Why after all theses years are will still sorting through 5 of this 4 of that to find the one that runs. At this point we still don't know what has or hasn't been fixed up for whatever problem it had and in a normal ready to go compilation. As time progresses the bad pennies keep overtaking the good stuff and we are back to trying to figure out why. Then we dig up the old answers after much frustration only to do some fixes and do it all over again.

 

Wouldn't it just be good to sort it out. You've done the work, why not have it stick and be done across the board.

Problem is, over time developers come with better solutions and we end up with multiple conversions. IMHO, it is better to publish the original works and the tools to create the conversions.

 

For example, here is a new version of the "romload.s" that install a little "handler" at LOMEM allowing the ROM to reload on RESET (only on XL computers), by enabling BASIC and thus protecting the RAM bellow. I tested it with Assembler Editor, Pilot and Logo, under DOS2, DOS25, SpartaDOS-3 and BW-DOS.

romload.s

  • Like 1

Share this post


Link to post
Share on other sites

Certainly not elegant, but in the spirit of using the AsmEd pretty easily and in a "bullet-proof" manner, I put it into a 27128 along with Basic and used a 2364 to 27XX adapter with a switch so I could boot to whatever I needed. These adapters were sold by Jim Brain at something like Retro Innovations. Pretty sure this is the same thing, but maybe a slightly different pcb than I have:

 

http://store.go4retro.com/2364-adapter/

or

http://store.go4retro.com/23xx-adapter/

 

BTW, that romload is a cool utility. Many, many years ago I tried to make something like that, but never got it to work correctly. It used to be so frustrating to hit reset on a cartridge image and have it crash!

  • Like 1

Share this post


Link to post
Share on other sites

Certainly not elegant, but in the spirit of using the AsmEd pretty easily and in a "bullet-proof" manner, I put it into a 27128 along with Basic and used a 2364 to 27XX adapter with a switch so I could boot to whatever I needed. These adapters were sold by Jim Brain at something like Retro Innovations. Pretty sure this is the same thing, but maybe a slightly different pcb than I have:

Yep those are the ones, I mentioned this in post #11 of this thread, but for use on the internal BASIC ROM - it should work just the same on the cart :http://atariage.com/forums/topic/284609-ed-assem-on-disk/?p=4148130

 

Does it fit inside the shell though with that adapter?? Maybe you had to ditch the base socket and solder pin headers directly between the adapter and the cart PCB?

Share this post


Link to post
Share on other sites

Oops! Sorry, didn't see your post. I really don't remember for sure, but I think that I just used a low profile socket. It seems unlikely that I would solder an adapter directly to the mobo. I may have used a shield that had "surgery." I had/have a Hako, so desoldering is not a big issue. It's still around here... somewhere. If I run across it, I'll post a picture.

 

-Larry

  • Like 1

Share this post


Link to post
Share on other sites

The problem becomes what of the six versions posted works for the most people. Why after all theses years are will still sorting through 5 of this 4 of that to find the one that runs. At this point we still don't know what has or hasn't been fixed up for whatever problem it had and in a normal ready to go compilation. As time progresses the bad pennies keep overtaking the good stuff and we are back to trying to figure out why. Then we dig up the old answers after much frustration only to do some fixes and do it all over again.

 

Wouldn't it just be good to sort it out. You've done the work, why not have it stick and be done across the board.

 

I can tell you by experience combing their archives that AtariOnline.pl multiple versions are often just this:

 

version 1: unpacked binary

version 2: packed binary

version 3: unpacked binary (same file as above) on ATR

version 4: packed binary (same file as above) on ATR

 

There may be other versions as well, but they're often nearly identical to these and ALL working fine. So,

it's more a matter of historical archiving, with the ATR versions just available for people who need or prefer

ATR's for their particular loading device.

Share this post


Link to post
Share on other sites
version 1: unpacked binary

version 2: packed binary

version 3: unpacked binary (same file as above) on ATR

version 4: packed binary (same file as above) on ATR

 

 

I guess that versions 4 and 5 are k-files.

If not then add these as well.

 

You missed the real disk images: :-D

version 5: plain ATR

version 6: plain ATR with read-only header-flag set

version 7: plain ATR copied to the first 720 sectors of an ED image

version 8: same content as XFD

  • Like 1

Share this post


Link to post
Share on other sites

I bought the cartridge to get started with 6502 assembly, i know there are better ways to do this... i probably end up using some cross assembler on a pc. But for now i just play around with the cartridge.

I've tried to enter some code, and i noticed that if i LIST code to the screen, the screen has problems scrolling up when it reaches the bottom of the screen? Anyone noticed this? it also f*cks up the code, for some reason it displays all lines that it needs to scroll, on the bottom line, and they also get inserted as code...

 

Is this a known 'feature'?

I thought i could solve it with a clearscreen command etc but it doesn't seem to exist... cls on the keyboard just moves the cursor top left.

Share this post


Link to post
Share on other sites

Something doesn't sound right there. What computer and OS are you running it on? I'm guessing something is wrong with the E: handler in the OS.

 

What happens if you print a listing that scrolls in Atari BASIC ?

 

How about listing a directory in DOS 2.0? (That should cause it to scroll)

Share this post


Link to post
Share on other sites

This happens when i just boot from the cartridge; there is no OS? This is a 600XL with 64K.

Scrolling in basic etc works just fine. I can test dos 2.0 and 2.5 etc to see what happens, played with it a bit prior but never noticed it.

Share this post


Link to post
Share on other sites

Just booted the cartridge again, all seems fine... a glitch in the matrix i guess :)

Share this post


Link to post
Share on other sites

... and now it is back again. Weird... look at pics, after starting i'm loading the source from disk, after that i do a LIST and the scrolling messes up at the bottom... 3rd pic is if i give a few RETURN keystrokes...

post-66363-0-63053000-1548180558_thumb.jpg

post-66363-0-17462600-1548180572_thumb.jpg

post-66363-0-11080400-1548180586_thumb.jpg

Share this post


Link to post
Share on other sites

I found "Atari Assembler Editor with DOS 2.0S.atr" somewhere, loaded it (with the cartridge in place, otherwise i just get a garbled screen, so i guess ed/asm is not included in the atr) and if i run the ed/asm i still get the scrolling errors. But... if i go to DOS 2.0, and there select B 'run cartridge' so i return to ed/asm, the scrolling is ok...

Share this post


Link to post
Share on other sites

The 8K ROM image may be burned into a Motorola 68764 or 68766 EPROM. It is pin compatible with Atari carts. I burned BASIC C into one. Works great. Only uses one socket of the BASIC cart.

 

Asm/Ed also works great with Incognito / U1M as a built in ROM image. Use UFLASH.

 

Ultimate (and other carts) are nice solutions as well.

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