Jump to content
IGNORED

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


luckybuck

Recommended Posts

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.org/wiki/Wiki.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:

 

post-32599-0-21265500-1473707447_thumb.jpg

post-32599-0-46267700-1473707453_thumb.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? :-)

MAC_XE_v3.4i_(1986-02-11)(Lawrow,_Stephen)(US).bin

MAC-65_v3.6_(1988-01-07)(Lawrow,_Stephen)(US).bin

Edited by luckybuck
  • Like 8
Link to comment
Share on other sites

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

 

 

MAC-65_v3.6_(1988-01-07)(Lawrow,_Stephen)(US)L.zip

 

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.

  • Like 1
Link to comment
Share on other sites

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:

post-32599-0-88992200-1473712884_thumb.jpg

 

post-32599-0-90535900-1473712906_thumb.jpg

 

post-32599-0-62130500-1473712923_thumb.jpg

 

  • Like 1
Link to comment
Share on other sites

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 :)

 

 

Basic_XE_v4.2_(1986-02-09)(OSS)(US)L.zip

 

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

 

post-18336-0-98944900-1473843154_thumb.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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Liner.zip

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

mymac-043m.bin

  • Like 2
Link to comment
Share on other sites

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 -- :)

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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