Mac 65 object file to Eprom, howto?

[guus.assmann]

Hello all,

 

I'd like some info on a problem that I've encoutered and need a way to fix it.

Using Alterra, I managed to compile a file and created an object file on the emulated drive. So the file is in the ATR and looks to be just fine.

Next step, export the file, using ASPEQT.

So now I have the object file on a windows based machine, ready to be programmed.

I loaded the file into the programmer and had a look with the editor.

The file should have been exactly $7FF bytes in size.

In the assembly on the emulated Atari it was !

But in the programmers edit buffer it was about $36 bytes bigger. (didn't check the actual number ! ) It started with 6 wrong bytes. I didn't check for the rest.

 

Where could I be going wrong?

Any better (and easy) ways to do this?

 

BR/

Guus

[+Stephen]

The 1st 6 bytes are FF FF (designates a binary file), then the next 4 are the load address and run address. The extra 30 bytes, I am unsure.

[+David_P]

Probably a segmented file. ANALOG had a program called the streamliner that solved that issue.

[pirx]

Exactly - MAC/65 output is segmented, i.e. has more load address segments than necessary. The trick to get rid of the headers was to load the binary but not run it, then save the memory block (easy under e.g. SpartaDos(X), DOSII+,DOS XL).

 

Nevertheless, you can not just burn Atari DOS object file to a cartridge eprom - these are very different formats. If you are not really deep into carts, the best choice for a starters would be a programmable cart like this one: http://www.atarimax.com/flashcart/documentation/.

 

Best,

 

pirx

[thorfdbg]

So now I have the object file on a windows based machine, ready to be programmed.

I loaded the file into the programmer and had a look with the editor.

The file should have been exactly $7FF bytes in size.

In the assembly on the emulated Atari it was !

But in the programmers edit buffer it was about $36 bytes bigger. (didn't check the actual number ! ) It started with 6 wrong bytes. I didn't check for the rest.

It isn't that easy. A binary load file and a cartridge are very different. For a cart, the Os (or actually the hardware) reserves memory space for the cart, and the Os starts the cart by going through the init and run address.

 

The init and run mechanisms for binary load files are very different. The file need to reserve memory for itself, that is, typically needs to move the display buffer out of the way. It usually also wants to install itself in a reset-proof way. That is, all in all, additional logic is required to make a cartridge binary workable as binary file. In case of the mac/65, however, additional logic is required since the ROM was also a bankswitched ROM, and I believe OSS provided a disk version that is assembled in a completely different way than the cart based version. You cannot simply take the disk version and write it to cart because additional logic is required in some places, and some logic from the cart will not be necessary for the disk version (bankswitching).

[Rybags]

The modern PC-based assembler tools are better for this sort of task since many allow generation of raw object files without any Binload headers.

 

But with Mac65 you could accomodate Eprom needs - just make the object file 6 bytes shorter than needed, it means you sacrifice those first bytes as junk at the start of the Eprom though.

[russg]

Hello all,

 

I'd like some info on a problem that I've encoutered and need a way to fix it.

Using Alterra, I managed to compile a file and created an object file on the emulated drive. So the file is in the ATR and looks to be just fine.

Next step, export the file, using ASPEQT.

So now I have the object file on a windows based machine, ready to be programmed.

I loaded the file into the programmer and had a look with the editor.

The file should have been exactly $7FF bytes in size.

In the assembly on the emulated Atari it was !

But in the programmers edit buffer it was about $36 bytes bigger. (didn't check the actual number ! ) It started with 6 wrong bytes. I didn't check for the rest.

 

Where could I be going wrong?

Any better (and easy) ways to do this?

 

BR/

Guus

ftp.pigwa.net doesn't seem to have Holme's ROMs correctly.

Here's Mac65 1.02 rom image. Should burn to eprom or run in Altirra, I guess.

edit: I just tried it in Altirra. It worked, but it is version 1.01. ....more here's Holmes mac65 1.01 rom, might burn better. It is 16k, 102 is 17k for some reason.

Mac65 1.02.zip

Mac65 1.01.zip

Edited April 3, 2014 by russg

[guus.assmann]

Thanks for the replies.

And it shows I have to eleborate a bit more.

My intention is to assemble an Eprom for a 1050 drive.

The source code is in Mac 65 format.

Running the assembler and storing the listing in the ATR works fine.

I can extract this to Word and edit it. The listing shows that the assembly was successfull and I can compare it with a working Eprom.

This shows that the source code is correct.

My next step is that I want to put this code into an Eprom emulator.

Once this works, I can start changing the parts that I need.

 

So the question is, how to get a file that I can put into the Eprom emulator or a real Eprom.

 

Yes, it's possible to do this with a PC-based cross assembler.

But it should work on the Atari as well.

Indeed it looks like segments in some way. But it can be that the process I use is wrong. Or there's a bug in ASPEQT.

Getting rid of the first 6 bytes is a job of seconds.

The programm I got for the Eprom burner has a copy function. So a copy from $006-$806 to $0 and it's done.

 

BR/

Guus

Edited April 3, 2014 by guus.assmann

[Rybags]

You can't simply burn Mac-65 or the other OSS carts to Eprom and use them, they're banked carts so need the relevant control logic to function.

 

Eprom emulator? What's that? I don't think there's any 1050 emulators out there that actually run 6502 code. Drive emulation is done at a higher level, so firmwares can't be easily tested, you'd likely need to do it on the real hardware.

 

Getting the file you want? Just ensure Mac-65 generates that contiguous 2K or whatever object file (+ header) - you'll have to strip out the header as you say, probably not an easier way from Atari-based Assemblers.

[ricortes]

I'm with Rybags on the switch to IBM style tools ending up being easier in the long run. Easily 1/3 the reason I switched to TASM was being able to generate naked binaries.

 

You can do it with native Atari tools like the Thompson Proburner that understand Atari file structure. Atari DOS always saves extra information you don't need in the file. I fooled around stripping the bytes, loading saving with MS DOS DEBUG and Atari BASIC. My EPROM burner at the time would accept a range to burn from so I would also do stuff like load an 8k cart image as a 16k EPROM and skip over the header and tail information on some files.

 

You can still add the extra 6 bytes of header information with TASM, just that you have to do it explicitly.

[flashjazzcat]

Not sure if this might be of some use:

 

DESEG.zip

 

(Needs SpartaDOS.) It takes a segmented binary file and removes the headers where segments are contiguous. Perhaps MAC/65 produces a 4 byte header every 256 bytes? I can't remember. Anyway: all you'll be left with is the initial 6 byte header, which you can then remove.

Edited April 3, 2014 by flashjazzcat

[guus.assmann]

Thanks flashjazzcat, I'll try the program.

 

@Rybags: An Eprom emulator, in the form I have it, is a device with a serial interface.

It can receive an Eprom file and write it to a Ram. (Binary or Intel-Hex)

Once all data is there, buffers are switched and a 28 pin socket will behave just like it's an Eprom.

This hardware emulated Eprom then can be used in the real hardware like the 1050 drive.

It is a very handy tool from the era where computer emulations were not that common. (And thats about 20 to 25 years ago.)

A Flashrom is just about the same, except the Eprom emulator is faster and needs no extra device.

Just use Dos and copy the file to the serial port.

However a programmer with a flash-rom will do the job just as well....

 

BR/

Guus

Edited April 3, 2014 by guus.assmann

[russg]

Thanks flashjazzcat, I'll try the program.

 

@Rybags: An Eprom emulator, in the form I have it, is a device with a serial interface.

It can receive an Eprom file and write it to a Ram. (Binary or Intel-Hex)

Once all data is there, buffers are switched and a 28 pin socket will behave just like it's an Eprom.

This hardware emulated Eprom then can be used in the real hardware like the 1050 drive.

It is a very handy tool from the era where computer emulations were not that common. (And thats about 20 to 25 years ago.)

A Flashrom is just about the same, except the Eprom emulator is faster and needs no extra device.

Just use Dos and copy the file to the serial port.

However a programmer with a flash-rom will do the job just as well....

 

BR/

Guus

I have a guess. You're trying to make your 1050 a US Dblr or Happy or other super drive. I know the USDBLR is two chips and a jumper. One chip is custom ICD.

[sup8pdct]

It depends on what computer the eprom writer is on. On an 8bit, any binary headers and segment data are stripped out by dos or the burner program so whats in memory is what will be written to the eprom. On any other computer, the binary load header and any segment data must be stripped out. I personally use Winhex to remove the 6 byte header.

 

James

[xzerix]

ftp.pigwa.net doesn't seem to have Holme's ROMs correctly.

Here's Mac65 1.02 rom image. Should burn to eprom or run in Altirra, I guess.

edit: I just tried it in Altirra. It worked, but it is version 1.01. ....more here's Holmes mac65 1.01 rom, might burn better. It is 16k, 102 is 17k for some reason.

 

The 1.02 file is the same as the 1.01 file, but with a 16-byte cartridge header for emulators - rename the extension from .rom to .car and altirra will recognise it

[guus.assmann]

@Russg,

You're almost right.

I have a partially working Super drive update.

It has 29F040 Flash and 512K Ram. (And XC9572 CPLD based logic)

So it has room for 16 (different) emulations of drive enhancers.

Currently, Super Speedy and standard 1050 are working fine.

Next step is to get the Flash-rom programmable on board.

That's why I need to be able to write code. I will test in a Happy-clone.

My first intention is to get a standard 1050 program to use the Happy track display.

This will be proof that I'm in controll and I can test some other stuff.

 

BR/

Guus

[Bryan]

This is so much easier with a cross-assembler. Just assemble to a raw binary file and use it for the EPROM. Using a native assembler is only worthwhile until it gets in your way.

[Rybags]

Especially if you do the Eprom burn from PC.

Although if using emulation there will usually be some facility to write out raw dumps of part of memory but it's a manual process that can be easy to do wrong.

[guus.assmann]

So a cross-assembler it should be.

Any recommendations?

I did try ATASM 1.06 but get an error code in line 37 that I cannot get rid of.

 

BR/

Guus

[Rybags]

AtAsm is good in that it's close in syntax to Mac-65 and can generate raw binaries but isn't high on capabilities. Make sure you have the later version, there were annoying bugs in early releases.

 

MADS tends to be the assembler of choice these days for many - actively supported with updates/improvements.

 

With either one, it's plenty easier to use a decent editor or an IDE which allows setting up macro/hotkey to do the calling sequence to perform the assembly rather than doing the save/command line assemble process.

[ricortes]

Really retro...

 

Upfront, whatever your source code is compatible with i.e. line numbered MAC/65 or not, directives, et al, I would go with a compatible assembler for it. On the other hand, there are tools that are the equivalent of Latin in that they are dead language that isn't going to change.

 

TASM is still available

http://home.comcast.net/~tasm/tasmdnl.htm

 

A while back I used it to get my feet wet with 5200 ROM coding. Attached is a quick demo mostly done by Dan Boris with just enough me to reassure myself I understood it.

 

Note that I had to name the file 5200rtc.txt because AA will not let me attach a file with the .src extension.

 

I am a fan of the new program editors. This was yet another slight mod because the original was loaded into Notepad and line length messed with the original. It should compile fine now once if you either give it the command line

TASM 5200rtc.txt -65 -b

Or rename it and use the command line given in the file with 5200rtc.src

 

I have to admit, fooling with this file to get it to work tonight I used a command prompt from Windows XP with "EDIT" command to edit the file. It isn't such a bad environment for programming. You have one command prompt window open for the TASM and just hit F3 to repeat last command line, another command prompt window with the file in EDIT, and an emulator open to test the file. EDIT is old and clunky but still works as a program editor because it gives line numbers so you can go right to the errors reference by TASM.

 

 

5200rtc.txt

[pirx]

Hello!

 

Blatant advertisement: there is our crossassembler (OMC65) that is more compatible to MAC/65 than atasm (atasm is better, though, just differs in some peculiarities like usage of dot in labels).

 

Grab it here (scroll down):

http://5oft.pl/?download.html

 

ST version has got some examples. For help just run omc.exe from command line. -A generates code without headers.

 

Just save MAC/65 as text file and strip line numbers with e.g.

sed 's/^[0-9]+ //'

 

Best,

 

pirx

[guus.assmann]

Thanks for the pointers and tips.

I'll try to find out what works for me.

The intention is just to get a little bit done. I'dd expect 200 lines or so.

 

BR/

Guus

Edited April 7, 2014 by guus.assmann

[ebiguy]

 

The 1.02 file is the same as the 1.01 file, but with a 16-byte cartridge header for emulators - rename the extension from .rom to .car and altirra will recognise it

 

Anyone having the "real" 1.02 version ?

It seems to be very hard to find one.

[ivop]

So a cross-assembler it should be.

Any recommendations?

I did try ATASM 1.06 but get an error code in line 37 that I cannot get rid of.

 

BR/

Guus

 

What error do you get? Could you bring it back to just a few lines that replicate the error and post it here? Or post the full file. Perhaps there is an easy fix.