Jump to content
IGNORED

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


luckybuck

Recommended Posts

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.

Thanks, Kr0tki for the interesting input on so many facets too. But that's interesting to me, I find that

sanny has an emulator that does 043M, but my Atari800Win 4.0 only does 034M like the Mac emulator.

Thanks to your comments, now I can understand how that came to be as it didn't make sense before

you started talking.

 

Can't help but wonder with 3.6 at 1988 copyright date VS 1.02 with 84 what did they do with the project for

four years? Nothing? This confuses me a bit. That's OK, it's normal for me.

 

mymac-034m.zip

sanny's file made into 034M order for 'Macs'.

(and Atari800Win 4.0)

  • Like 1
Link to comment
Share on other sites

Quite easy 1050:

 

If you go here:

https://atariwiki.org/wiki/Wiki.jsp?page=Mac65

the last point under MANUALS, there is a printout of the complete(!) assembly with all words, commands etc. in text format. So then, we know everything. :-)

If the community does the same with BASIC XE 4.2 while assembling, that would be cool. Just an idea...

Link to comment
Share on other sites

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 was using XDOS 2.4. Tried again with DOS 2.5 and there the error won't happen there, too.

 

 

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 compiled again with the "@" macro unchanged, and the errors don't prevent the output file from being generated. The "@" macro makes sense to me now ;-)

 

 

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.

 

 

Ok. So it's correct to use (RAM=0,EPROM=1) to generate a cartridge 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.

 

 

Hmm, yes. That's also a way to do it :)

 

 

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.

 

Thanks for the interesting information!

  • Like 1
Link to comment
Share on other sites

But that's interesting to me, I find that

sanny has an emulator that does 043M, but my Atari800Win 4.0 only does 034M like the Mac emulator.

 

 

I'm using atari800 (https://sourceforge.net/projects/atari800) on Linux, latest development version. Don't know if the latest released version of it also supports 043M.

Maybe the Windows and Mac ports need to be updated.

  • Like 1
Link to comment
Share on other sites

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.

Ah, OK. Sorry for jumping to conclusions then.

 

So, these are not straight images from the original development disks. What format were the file originally in, then? Were they modified in any way when transferred to these ATRs? Some of the images contain already-assembled binaries of MAC/65 and other tools; do these files also come from the original medium, or were they added by yourself in the process?

 

See, I hugely appreciate the whole effort of rescuing and publishing the source codes, but, releasing a disk image with historical artifacts without documenting the actual file retrieval process, and without any information about which files are original and which are not, well, that's a shoddy way of doing digital archaeology.

 

 

But that's interesting to me, I find that sanny has an emulator that does 043M, but my Atari800Win 4.0 only does 034M like the Mac emulator. Thanks to your comments, now I can understand how that came to be as it didn't make sense before you started talking.

Here's the full story: There were two versions of OSS Supercartridges: the earlier one with two 8Kb chips, and the later one with one 16KB chip. The 034M and 043M are two ROM image formats of the two-chip cartridge. They both exist concurrently because historically there were two methods of cartridge dumping that resulted in these two incompatible formats.

 

Dumping the ROMs using an EPROM reader results in two files, one with the "3M" banks, the other with the "04" banks. To make a 16KB image one needs to joint these two files together, and it can be made in two ways. Apparently, the person or people who created the available ROM dumps, consistently chose to use the "043M" order; luckily, no 16KB file with the "3M04" order ever surfaced on the Internet.

 

Now, David Firth apparently didn't know all about this internal cartridge structure when he was adding OSS cartridge support to Atari800 back in the late 90's. He probably obtained the ROM images by putting an OSS cartridge into an Atari and using a program that sequentially selected different banks and wrote them to a file. And the most obvious order of reading banks is from the lowest to the highest number. Hence the 034M ROM image format was born.

 

As a result, ROM images in two formats were available for download from many websites, but for years emulators only supported the 034M format. I finally added support of the 043M format to Atari800 in 2011, and other emulators soon followed. But Atari800Win and Atari800MacX are not maintained for years, so the 043M format hasn't reached them yet.

 

I was using XDOS 2.4. Tried again with DOS 2.5 and there the error won't happen there, too.

See, apparently Atari DOSes ignore filename characters after the 8th one.

 

Ok. So it's correct to use (RAM=0,EPROM=1) to generate a cartridge image.

Yes. Well, technically, (RAM=1,EPROM=0) is also the correct way, but it needs a bit more work to retrieve a ROM image from the resulting binary :-)

 

I'm using atari800 (https://sourceforge.net/projects/atari800) on Linux, latest development version. Don't know if the latest released version of it also supports 043M.

Yes it does, for a few years already.

 

Maybe the Windows and Mac ports need to be updated.

Sure they do. Until it happens, it's best to get the Windows or Mac version of vanilla Atari800, or use another emulator.
  • Like 1
Link to comment
Share on other sites

Hi KrOtki,

 

As I have written in the 1st post:

"

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

"

I don't know, who send me the package, there wasn't even a stamp on it! So I really don't know from what country this was comming. All inside were microfilms with hex codes à la: A9 02 40 and so on. No comments, no traces, nothing. Just the file name above a new block of codes, that was all.

 

I guess, a good soul out there, has seen:

https://atariwiki.org/wiki/Wiki.jsp?page=Articles#section-Articles-SourceCode

?

But I am just guessing. Same is true for Calculater at the very bottom of the site:

https://atariwiki.org/wiki/Wiki.jsp?page=Atari%20Calculator

here, I guess, that a high person in a high castle must have seen this. In late 2015 Microsoft finally fixed it. Wonders are still happening. :-)))

 

All inside my package were microfilms with hex code à la: A9 02 40 and so on. No comments, no traces, nothing. Just the file name above a new block of codes. That is all. So, from February to now, we typed in all the codes, hope we did it right, then we had to convert all(!) files:

https://atariwiki.org/wiki/Wiki.jsp?page=Create%20a%20BIN%20file%20out%20of%20a%20HEX%20file

and then I put the files to images most used by us, so they fit near the disk capacity.

Then from there on, we were able to create the first carts. That was a bunch of work, but the community, and your are a big player in it, could finally done it. The story so far.

I haven't edited any source by myself, I kept them 1:1, hope desperately, my eyes didn't left me behind.

Sure, that is a strange way for preserving, but what is the alternative? Do we really have one? I mean, this is real life, this is not:

https://en.wikipedia.org/wiki/Kobayashi_Maru

where we can alter the reality to win finally. We have to accept, what is given to us. I am really sad for that, but if, then I would start the mass production of 1200XLs tomorrow... ;-)

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

So you typed in the files from hex dumps? Thank you very much for this effort. Hats off!

 

So someone back then invested quite some effort to make a long-term backup by printing the files and converting them to microfilm.

 

I'm wondering about the reason he requested you to destroy them afterwards. Somehow contradicts the initial reason to create the films.

 

I can only guess about that, but two plausible reasons come to my mind:

  • the backups were unauthorized (IOW stolen) and the films could give hints to who did it
  • he wanted to prevent you or somebody else to make huge $$$ out of them by selling them on Ebay in 30 or 50 years (or maybe even now, don't know for how much they could go)

Anyway, great effort!

  • Like 1
Link to comment
Share on other sites

Hi sanny, :-)

 

You really don't know what I would do to bring this list:

https://atariwiki.org/wiki/Wiki.jsp?page=Rarity%2010

to zero. ;-)

 

Well, I had the same feelings like you, therefore, we made it really big. We have green light from:

Paul Laugthon, Kathleen O'Brien, the Wilkinson family, Tom Harker and many more, further we have send 2 messages to Mike Hohman and asking for permission, a long time ago. At least he didn't say "NO". Therefore, I think, it is o. k.. On the other hand, I think, I don't have that much time left, that is why I am in a hurry with that. But who knows.

I would be glad to see all OSs and major languages in PD, so Atari can go on forever.

 

See you out there in the galaxy.

post-32599-0-21930500-1474034289.jpg

 

  • Like 1
Link to comment
Share on other sites

Hi KrOtki,

 

As I have written in the 1st post:

"

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

Okay. Thank you for the explanation. Frankly, I had read your first post before asking, but it was a bit cryptic and confusing, an evidence of a language barrier at play. That post sounded to me like you were joking about these microfilms, trying to spice the post up with some James Bond-esque story for a bit of good-natured fun.

 

Still, I think this whole information about the microfilms should be documented right there on AtariWiki.

 

Anyway, typing in all the files was a lot of work, and I thank you for that. Hopefully you used some OCR software for help.

 

Then from there on, we were able to create the first carts. That was a bunch of work, but the community, and your are a big player in it, could finally done it. The story so far.

 

I haven't edited any source by myself, I kept them 1:1, hope desperately, my eyes didn't left me behind.

Right, but as confirmed earlier, some files on the disks aren't from the microfilms (eg. DOS system files). The wiki page should contain a clear description of that fact. And let me ask again, are there any other files on these ATRs, that were not on the microfilms?

 

Sure, that is a strange way for preserving, but what is the alternative?

To make myself clear, I am not criticizing the whole process of preservation, only the fact that the process, and the contents of the ATRs, are poorly described.
  • Like 2
Link to comment
Share on other sites

Still, I think this whole information about the microfilms should be documented right there on AtariWiki.

 

Anyway, typing in all the files was a lot of work, and I thank you for that.

 

Right, but as confirmed earlier, some files on the disks aren't from the microfilms (eg. DOS system files). The wiki page should contain a clear description of that fact.

 

I wholehearted agree with all of these statements.

Link to comment
Share on other sites

@KrOtki:

You wrote:

"

Okay. Thank you for the explanation. Frankly, I had read your first post before asking, but it was a bit cryptic and confusing, an evidence of a language barrier at play. That post sounded to me like you were joking about these microfilms, trying to spice the post up with some James Bond-esque story for a bit of good-natured fun.

"

I am sorry, but that was the truth... :-(

 

"

Still, I think this whole information about the microfilms should be documented right there on AtariWiki.

"

Sure, but we can do those things at any time. 1st to me is the rescue mission. Take for example, that Bill Wilkinson has left us. All his knowledge is gone, until we save it for generations to come. Therefore, this must be 1st. At the moment, I am very close to get a final status of the source code of TurboBasic XL. The author has left us in 2011, so, this is not an easy one and very time intensive.

 

"

Anyway, typing in all the files was a lot of work, and I thank you for that. Hopefully you used some OCR software for help.

"

Well, if you thank me for that, which is very much appreciated, how can we thank you, for all you have done?

I am sorry, but OCR didn't worked here. Take the source code of the Atari Calculator for example. There is no way around with the given original, then to type in manually. But I think it is worth the time. Today, you proved once more with providing us with the integer basic cart. Which is the BASIC version of ACTION! due to the lack of FP. I guess, there will be much attention about that version in the future.

 

"

Right, but as confirmed earlier, some files on the disks aren't from the microfilms (eg. DOS system files). The wiki page should contain a clear description of that fact. And let me ask again, are there any other files on these ATRs, that were not on the microfilms?

"

Yes, you are right, all DOS files are form me, further all Color DOS and the COLOR.OBJ else AUTORUN.SYS file, which changes the color to light gey background and black letters. My eye doctor said, this is best. White background & black letters, like here. :-)

All(!) the other stuff is from the microfilms. I took always an atr which could take all files at once. If there was place, I put a DOS on, if not, I leave it. I took the Atari DOS, because I think that most users can deal with it. I am not that fit in SpartaDOS, nor do I have a SD cart from the old times.

 

"

To make myself clear, I am not criticizing the whole process of preservation, only the fact that the process, and the contents of the ATRs, are poorly described.

"

 

I really didn't take it this way. By the way, you are right. But again, where is the alternative? As you mentioned, you took MAC/65 1.02, a version published in the last time from AtariGeezer. Now, in the very near future, I think, it will change to 3.6...

Therefore, I can't be that far away...

 

My main goal is to bring the Rarity 10 site at the AtariWiki down to zero, then I can continue with the documentation. But I am always open for improvements.

Edited by luckybuck
Link to comment
Share on other sites

  • 1 year later...
  • 7 months later...

Hi Alfred,

 

:-)

 

That is difficult to answer...

 

As far as I am in that, it started with MAC/65 in 1.0, 1.01, 1.02 als cart version, 2.x as disk version up 4.2 under ICD & FTe, then long, long nothing... then XL, then XE and again MAC/65 with the latest version 3.6 from 1988. Still unclear is, whether the XE or 3.6 version uses the extended RAM from the XE. My dream is, the use of up to 4 MB RAM and with the editor from ACTION! you extracted the last days... :-)

 

I have made here:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Assembler

 

an overview of the opcodes, which should or actually are already in version 3.6....

 

Hope, I could help?

Link to comment
Share on other sites

Has anybody discerned what the difference is in it ? I tried browsing the ROM and didn't notice any new commands like EXTEND and trying a few things like that didn't yield any results. A long time ago I was thinking of using the Action! editor as an editor for the Six Forks Assembler but also modifying it to tokenize the text to give a faster speed of assembly. My XE version of the Action! editor works, but I think the display glitches sometimes due to the bank switching. I'll have to take a look at it to see what the problem is with it.

 

As for Mac/65, other than say adding 65816 mode to it, and maybe use of XE ram, I don't think there's much it needs. It's a first rate assembler the way it is now.

 

I also found my port of SPF/PC. If I can figure out how to use VBXE I might update it, cuz it really needs 80 columns to be useful. I think from another post there was two people who might find it amusing to use SPF on an Atari instead of a 3277. Ahh, the thrill of typing COLS again, lol.

  • Like 2
Link to comment
Share on other sites

@MrFish: https://atariwiki.org/wiki/Wiki.jsp?page=Mac65 please take here the 2nd ATR: 1982 by SDL, then OSS, then ICD, then FTe.... all correct.

 

@Alfred: Yes, maybe it is a good idea, to load the source codes into modern editors, like Sublime Text, UltraEdit and so on and check from there on? Even comparing the code could be useful. My vision for the one and only MAC/65 in the final version or let's call it: Ultimate MAC/65 with respect to SDL, would be the same as my vision for Ultimate Basic:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Ultimate%20Basic

 

and of course for ACTION!, Pascal, Forth and maybe FORTRAN(?)... who knows...

Link to comment
Share on other sites

As far as I am in that, it started with MAC/65 in 1.0, 1.01, 1.02 als cart version, 2.x as disk version up 4.2 under ICD & FTe, then long, long nothing...

 

So, you should correct this... both disk versions came first: 2.0 & 4.2, then the cart versions afterwards.

Edited by MrFish
Link to comment
Share on other sites

It's the same version. Do a file compare. The only thing changed by FTe was adding their name and a new date, which equals nothing.

 

I guess I should state this more clearly: the FTe version 4.20, stamped 1994, is exactly the same as the OSS version 4.20 with a copyright date of 1982;

the only difference in the file being the text with FTe, 1994, and some other bits of text that get printed on the startup screen together.

Edited by MrFish
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...