Jump to content

Photo

OSS-D-Day part 2-MAC/65 >1.02-cart&source now in PD

OSS MAC/65 MAC XL MAC XE source code

67 replies to this topic

#1 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • 957 posts

Posted Mon Sep 12, 2016 1:13 PM

Hello together,

Today is a very special day, because a long, long search and work around the world with many users is now over with a final good end after decades.

The community now has the lost to be believe, final OSS supercart of the highest developed macro assembler for the Atari, the OSS MAC/65, MAC XL and MAC XE in various versions and this time with the source code together!

Did I mention the additional commands like PHX, PHY and so on?  ;-)

We are very happy about that, because now, we can make a final macro assembler for the Atari, let's call it: Ultimate MAC/65?

Further, we can interbreed with other source codes, for example ACTION! for an enhanced editor (scrolling) or the EXTEND command from the source code of BASIC XE to get used of the additional RAM with now up to 4 MB! All this is now possible and to your feet.

All links to the software can be found here:

https://atariwiki.or....jsp?page=Mac65

Enjoy and have fun. :-)))

This service was brought to you by Kevin, a good soul (who would like to stay anonymously), JAC!, Tomasz 'KrOtki' Krasuski, a still unknown donator of the hex codes, which enabled us to restore the code, the files and later from that, finally, the cart itself.

For those of you, who may ask about the unknown donator: in the very last picture of the microfilm there was a slide with the following sentence:

After digitizing, destroy everything send to you and there will be more!

I did exactly as ordered, and guess what, we can continue in part 3! Not kidding. Check back in here again. :-)
 

 

Call for help, up to now, we have some problems with assembling, just 4 errors are remaining:

 

pic1.jpg

pic2.jpg

Who can help us to get them lost?

 

The BIN-files just run in Altirra with OSS '043M' ; who can create a '034M'-version? :-)

Attached Files


Edited by luckybuck, Thu Sep 15, 2016 4:49 AM.


#2 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Mon Sep 12, 2016 2:26 PM

Not sure why you want that, but here is my attempt at 034 versions.


Attached File  MAC-65_v3.6_(1988-01-07)(Lawrow,_Stephen)(US)L.zip   26.52KB   150 downloads

Let me know if they work for you and I'll do the others in the other
thread too. Again not sure if this is what you even want or why.
Notice the added L on the end of the filename.

Wow -- we have it. I'll take a shot at fixing errors and see how
confused I can get by that.

Kudos luckybuck and team.

#3 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Mon Sep 12, 2016 2:43 PM

Kudos ^2 1050!!! We are sitting here getting our heads red and still have no ideas over so long and you solved it in a flash!!!!!!!!!!!!

Yes, breakthrough! It works! I can't believe it! :-))))

The problem was to get a 034M version, so the Mac-users can take in their emulator, please see below the attachments. To test it, you can input LIST and the 043M-version will hung up.

Now, your version runs! and both of them! Can you it again for BASIC XE? :-)))

Would you be like in the AtariWiki by:

a) full name

b) 1050

c) none of both, just as a good soul?

 

Please don't let me die stupid, what have you done? Must be ultra quick...

 

Mega-thanks, you helped the community a lot! :-)))

 

Mac-Emulator carts only:

034M.jpg

 

3.4i.jpg

 

3.6.jpg

 



#4 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Mon Sep 12, 2016 3:31 PM

Oh, fantastic news then.

Hey, I might even be able to remember how. :)

Ok, a rundown of how these OSS cart images are laid out. Their bank number is found at real
address of 0xAFFF in the Atari system. In the image then these are found at 0x0FFF, 0x1FFF,
and 0x2FFF offsets into the image. Since 043 is what we have, we cut a block of 0x1000 size
starting at 0x1000 and paste it 0x1000 bytes further into the file which changes the order
to 034.

Good soul works for me, if it took all day then I might need more :)


Attached File  Basic_XE_v4.2_(1986-02-09)(OSS)(US)L.zip   12.71KB   138 downloads

I recall a similar screen in Atari800Win too, but don't remember the available
choices there. So now I understand the why of the need.

#5 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Mon Sep 12, 2016 3:35 PM

You are soooooooo welcome... :-)

 

Please go ahead!

 

Thank you so much, especially in the name of the Mac-Users. :-)))



#6 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Mon Sep 12, 2016 4:04 PM

Most welcome right back and glad to be of service anytime.

We do have to take care of our McCousins after all.

#7 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Mon Sep 12, 2016 4:43 PM

Can anyone explain to me this 034 or 043 thingie?



#8 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Mon Sep 12, 2016 6:17 PM

It's an adopted nomenclature type of deal that got applied to OSS supercarts due to the
somewhat unique way they do this style of supercart. In their system, no matter what
bank is selected, the back half of the cartridge window remains the same. That would
be 0xB000 thru 0xBFFF. Selecting a bank then only changes the front half of the cart
window at 0xA000 thru 0xAFFF. No need to hang the back half off of each of these when
making a rom image, the model came from the code as stored in the eprom where the back
half is at the rear end of the eprom and the changeable portions consist of the front
part of the eprom. These are ordered by their banking bytes, 043, 034, and 091. The
reason there are different orders depends on how the cart board is made and what
connections work which logic chips that make the above work in that design. There was
first a two eprom board which used one banking scheme, ending with a single eprom type
of the 091 flavor IIRC. 091 type requires a change within the code to store a 9 instead
of a 3 or 4 to 0xD500 in order to bank in the 'second' bank. Doing a 043 for 034
change then didn't require this extra effort in converting the code.

All this really only became a standard when emulators came onto the scene and a
common and easily understood method became necessary to describe the function of these
carts. As such it's not in real book, just floating around in the minds of old men.
It probably is in the manual for Altirra though, consider that the factual information
source and the above to be possibly erroneous ramblings.
  • slx likes this

#9 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Tue Sep 13, 2016 7:38 AM

Thanks, 1050



#10 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Tue Sep 13, 2016 8:09 AM

I'm trying to compile mac-xl-1.atr/mac-xl-2.atr with MAC/65 1.1 and I'm getting this:

 

atari002.png

 

 

what should DDTBANK2+3 be? it's not a valid filename

 

atari001.png

 

 

Btw., how do I insert images directly into a post?



#11 fujidude OFFLINE  

fujidude

    Quadrunner

  • 5,217 posts
  • Location:United States of America

Posted Tue Sep 13, 2016 11:39 AM

Btw., how do I insert images directly into a post?

 

I've wondered the same thing.



#12 Stephen OFFLINE  

Stephen

    Quadrunner

  • 7,463 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Tue Sep 13, 2016 11:42 AM

Surround the image URL with img tags - [ img ] URL [ /img ] (No spaces)

OR - upload the image to the site, and use the insert image in post link (when posting, you will need to click the "Use Full Editor" button.



#13 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Tue Sep 13, 2016 12:04 PM

My guess would be to find DDTBANK3 and if exist then

Make a new line
1585     .INCLUDE #D2:DDTBANK3
then trim +3 from line 1580

try again?

Just how this all came about is of course the question without a real answer.
Life is like a box of chocolates, you never know what you are going to get.

Not sure at all why you would ask about posting photos into a post after I
see two photos in your post. If it's a remote site, you can just paste the
url and Albert's fine posting machine will produce a clickable link out of
it.

Orange More Reply Options button takes you to page that has Attach Files
footer on the reply box and it works on local to you photo files. Once
uploaded from your computer a link will show up that pastes the photo to
where you left the cursor in your message.

#14 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Wed Sep 14, 2016 2:57 AM

My guess would be to find DDTBANK3 and if exist then

Make a new line

1585     .INCLUDE #D2:DDTBANK3
then trim +3 from line 1580

try again?

 

 

There is no DDTBANK3 file.

 

 

 

Just how this all came about is of course the question without a real answer.
Life is like a box of chocolates, you never know what you are going to get.

 

 

Seems like the "+3" was intended as a comment. And the space before it somehow got lost.

 

If I comment the "+3" I get a similar result like the OP:

 

atari003.png

 

 

 

Not sure at all why you would ask about posting photos into a post after I
see two photos in your post. If it's a remote site, you can just paste the
url and Albert's fine posting machine will produce a clickable link out of
it.

Orange More Reply Options button takes you to page that has Attach Files
footer on the reply box and it works on local to you photo files. Once
uploaded from your computer a link will show up that pastes the photo to
where you left the cursor in your message.

 

 

Yes, I've noticed that, too, after writing the post.

 

But I had to copy the pictures to a web server and then add the link to the picture to the post. This was a bit cumbersome.

 

I now tried your suggestion, seems to work. Thanks!



#15 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Wed Sep 14, 2016 5:04 AM

I got it to compile with the following change to MASTER:

--- MASTER      2016-09-14 12:54:31.656143139 +0200
+++ M2  2016-09-14 12:54:37.759181364 +0200
@@ -52,7 +52,7 @@
        .SET    5,16    comment padding
        .PAGE   "ASSEMBLY MACROS"
        .MACRO  @ 
-:BR0   .=      *+%1
+;:BR0 .= *+%1
        .ENDM
 ;
        .MACRO  BANK 
@@ -155,7 +155,7 @@
        .INCLUDE        #D:BANKC1
        .IF     DDT?
        .INCLUDE        #D2:DDTBANK1
-       .INCLUDE        #D2:DDTBANK2+3
+       .INCLUDE        #D2:DDTBANK2 +3
        .INCLUDE        #D2:DDTBANK4
        .INCLUDE        #D2:DDTBANK6
        .INCLUDE        #D2:DDTBANK7

I have only found four occurrences of the "@" macro, all in the MASTER file.

 

So, instead of commenting the body of the macro, "@" could be removed completely (definition and usages).

 

The macro as written is supposed to advance the location counter by <argument>.

 

But:

  • no usage of the macro has a parameter (therefore the compile errors)
  • the location counter is set to some value anyway directly after the macro invocation

I'm wondering where this "@" macro is coming from and why it is there.

 

I've compiled with (RAM=0,EPROM=1) and (RAM=1,EPROM=0). Both of them worked and give different output files.

 

I'm wondering what the "RAM cart" is, mentioned in the comment of RAM.

 

So, now I have output files in Atari EXE format with many load segments (like MAC/65 does). How do I convert them to a ROM image?

 

I've tried the MOVE.COM and FILLFF.COM programs on D2:, but they just flash a message on the first line of the screen (too fast to read).

 

regards,

chris



#16 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Wed Sep 14, 2016 5:06 AM

There is no DDTBANK3 file.
 
 
Seems like the "+3" was intended as a comment. And the space before it somehow got lost.
 
If I comment the "+3" I get a similar result like the OP:


Ok, not the end of the world if DDTBANK3 doesn't exist. For all we
know it's been folded over into DDTBANK2 and that is supposed to be
a comment just like you propose. I didn't see that one myself at all.
You've got a good eye for this kind of work and you've posted just
the right photos too.

In this source I've noticed that tendency to use a space as a comment
delimiter, but in my experience with MAC/65 it's always best to use
the semi-colon.

There seems to be a bug where the space works in some places and
in others it doesn't. But the semi-colon solidly makes it happen
every time. If our source code donator missed that memo then
a lot of these mistakes can show up. Make it a semi-colon comment
and see if the code compiles then. I like more than one or two
spaces before the semi-colon too, but that might be a habit I
had to adopt back in the days of using disk based MAC/65. One
version would not allow a comment of any kind on the same line
as a label -- drove me stark raving mad trying to figure out what
was wrong that time.
Thank you for doing the leg work, I haven't tried just yet.

And confusion over posted photos all good now, seems there are
several ways to do it and learned something myself too.

#17 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Wed Sep 14, 2016 5:58 AM

I'm wondering where this "@" macro is coming from and why it is there.
 
I've compiled with (RAM=0,EPROM=1) and (RAM=1,EPROM=0). Both of them worked and give different output files.
 
I'm wondering what the "RAM cart" is, mentioned in the comment of RAM.
 
So, now I have output files in Atari EXE format with many load segments (like MAC/65 does). How do I convert them to a ROM image?
 
I've tried the MOVE.COM and FILLFF.COM programs on D2:, but they just flash a message on the first line of the screen (too fast to read).


Not sure on unused macro other than I don't care for it.

I'm suspecting they used a different assembler than MAC/65 and it might have
required (RAM, EPROM) for a reason I can't know.

I use streamliner to de-segment MAC/65 output files, you will still have to strip
the first six bytes with a hexeditor of course. Renamed to liner on this atr,
one has to have the file on the atr with liner because it does not allow a
change from D1:, it also does not allow a return to DOS -- PIA but it works.

Attached File  Liner.zip   10.95KB   124 downloads

#18 fujidude OFFLINE  

fujidude

    Quadrunner

  • 5,217 posts
  • Location:United States of America

Posted Wed Sep 14, 2016 10:08 AM

Surround the image URL with img tags - [ img ] URL [ /img ] (No spaces)

OR - upload the image to the site, and use the insert image in post link (when posting, you will need to click the "Use Full Editor" button.

 

Thanks.  I have been using the 2nd method but it's a bit inconvenient.

 

ea3dcff8ed8e8939d98c96b81f747623.jpg


Edited by fujidude, Wed Sep 14, 2016 10:09 AM.


#19 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Wed Sep 14, 2016 3:26 PM

I use streamliner to de-segment MAC/65 output files, you will still have to strip
the first six bytes with a hexeditor of course.

 

This somehow didn't work. The de-segmented file was only 16236 bytes long, when it should be at least 16384 bytes.

 

But I managed to make a working version.

 

I've compiled with (RAM=0,EPROM=1).

 

Then I've used Hias' "ataricom" tool to de-segment the file. I've stripped the first 6 bytes to get a ROM image.

 

The segments were in wrong order (3M04), so I swapped the first and second 8K of the image.

 

Loaded it into atari800, and voila, the cart was recognized and I was in the MAC/65 editor.

 

As test I recompiled the sources with this version and the resulting file is identical to the version compiled with MAC/65 1.1.

 

For reference I'm attaching my binary image.

Attached Files



#20 1050 OFFLINE  

1050

    Stargunner

  • 1,065 posts

Posted Wed Sep 14, 2016 4:55 PM

Good work there.

I'll have to double check that the posted liner is working as usual here as well as get
and use the Hias tool, odds are it's better anyway.

Interesting that the build is so mixed up as to wrong order. It seems then that one
might re-order the include files to build either version of 034M or 043M then? Even
091M isn't outside the realm of possibles too, but some source tweaking might be needed
there.

sanny for the win -- :)

#21 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,133 posts
  • Location:Warszawa, Poland

Posted Wed Sep 14, 2016 7:31 PM

I'm trying to compile mac-xl-1.atr/mac-xl-2.atr with MAC/65 1.1 and I'm getting this:

atari002.png


what should DDTBANK2+3 be? it's not a valid filename

It depends on the DOS being used. Stephen D. Lawrow used DOS 2.0D for MAC/65 development (it is included in the 1988 sources of MAC/65 v3.6 also available at AtariWiki: mac-xl-master-3.6-1988.atr). Assembling under DOS 2.0D does not raise this error.

 

I have only found four occurrences of the "@" macro, all in the MASTER file.

So, instead of commenting the body of the macro, "@" could be removed completely (definition and usages).

The macro as written is supposed to advance the location counter by <argument>.

But:

  • no usage of the macro has a parameter (therefore the compile errors)
  • the location counter is set to some value anyway directly after the macro invocation
I'm wondering where this "@" macro is coming from and why it is there.

Sources of BASIC XE 4.2 (also released recently on AtariAge) contain the @ macro as well, but with an additional comment indicating that its purpose is to display memory location at which a cartridge bank ends. Ie. if it passes $AFFF or $BFFF, then we're in trouble, because we're trying to assemble too much code into a bank.

The macro functions by raising ERROR 32, which also displays the current assembly address. The error is otherwise harmless - the sources assemble correctly even without modifying the macro like you did.
 

I've compiled with (RAM=0,EPROM=1) and (RAM=1,EPROM=0). Both of them worked and give different output files.

I'm wondering what the "RAM cart" is, mentioned in the comment of RAM.

While (RAM=0,EPROM=1) results in a binary file that loads its four banks sequentially to $3000-$6fff, (RAM=1,EPROM=0) creates a binary file that loads itself to cartridge area, ie. $a000-$bfff. It also contains segments that switch cartridge banks by writing to $d5xx, inbetween the segments with bank contents.

Apparently OSS used a RAM cartridge for development of their products. The cartridge was compatible to their standard ROM cartridge with regards to bank-switching, but contained RAM instead of ROM. The file would load itself into correct banks of the RAM-cartidge, which would result in a functioning MAC/65 cartridge, immediately available for testing.
 

So, now I have output files in Atari EXE format with many load segments (like MAC/65 does). How do I convert them to a ROM image?

When assembling the aforementioned MAC/65 v3.6, I just loaded the file to memory, and dumped the contents of $3000-$6fff to file using the memory dump function available in the emulator's debug monitor.
 

Interesting that the build is so mixed up as to wrong order.

Not that interesting. An OSS "Supercartridge" contains two 8KB EPROMS, one of them contains banks "0" and "4", and the other contains banks "3" and "M". When creating a ROM image of such a cartridge, one has to dump the two EPROMS and join them to create a 16KB file. When the first OSS cartridges were dumped back in the 90's, someone decided to join the two EPROM images in the "04" + "3M" order, hence the "043M" mapping used by emulators. MAC/65 sources simply assume the reverse order of EPROMs.

Edited by Kr0tki, Wed Sep 14, 2016 7:45 PM.


#22 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Sep 15, 2016 2:15 AM

@sanny: You wrote: MAC/65 1.1   sanny, maybe I am stupid or blind or both, but as far as I know, there is just 1.00, 1.01 and 1.02 for the carts sold. If you really have a 1.1 version, I would like to talk to you to get it for the Wiki.

 

@KrOtki: You wrote:

"

It depends on the DOS being used. Stephen D. Lawrow used DOS 2.0D for MAC/65 development (it is included in the 1988 sources of MAC/65 v3.6 also available at AtariWiki: mac-xl-master-3.6-1988.atr). Assembling under DOS 2.0D does not raise this error."

 

Well, I don't know, what Stephen uses, all I can say, I am guilty 100 % to put the files on 2.0D disk images, in order that most of the users can read them in. I had assembly errors with my Mac emulator when using a 130XE machine, but not when using a 800 machine with OS B regarding Integer Basic. Totally crazy, but true. Further, we should go back in time in our minds, to imagine what authors may have used in 1988 when it comes to a DOS you can work with. In my opinion it should be at least DD.

 

It took from February to now to get all the hex byted to files, we can work with. I have always used a disk format, which can hold all the files at once.



#23 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Thu Sep 15, 2016 4:15 AM

@sanny: You wrote: MAC/65 1.1   sanny, maybe I am stupid or blind or both, but as far as I know, there is just 1.00, 1.01 and 1.02 for the carts sold. If you really have a 1.1 version, I would like to talk to you to get it for the Wiki.

 

I meant to write 1.01. Sorry for the confusion.



#24 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Sep 15, 2016 4:48 AM

Don't worry, then try the 1.02 version and assemble from disk to disk please.



#25 sanny OFFLINE  

sanny

    Moonsweeper

  • 358 posts
  • Location:Bavaria

Posted Thu Sep 15, 2016 7:51 AM

Why?







Also tagged with one or more of these keywords: OSS, MAC/65, MAC XL, MAC XE, source code

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users