Jump to content
IGNORED

Rolling your own ROM files?


Recommended Posts

atarimax.com has a device that will do that for you.

 

Mitch

I guess you're talking about the APE Warp + 32 in one OS. For $50 plus $4 ship. Or maybe I don't know what Atarimax.com item you're talking about.

The 32 in 1 OS has Omnimon as one of the OS.

Omnimon used to be sold by Newell as a 3 in 1 switched OS that simply plugged into the OS socket on a 800XL (probably on 65/130 XE also).

Once you have the custom OS, you gotta learn how to use it.

You power up your computer with the cart inserted no DOS loaded Or some people do a hot insert after the computer is on.

I don't recommend a hot insert.

Either way, you have to have the cart in. I don't think you have DOS loaded, Omnimon has its own disk functions.

Now it gets a little involved. You enter the Omnimon ml monitor with RESET + SELECT. I would guess RESET/SELECT is how

you enter the Warp 32in1 menu.

After you enter the ml monitor, you hit a keystroke combination to save memory to sectors on a single density disk.

That's where you say write $A000 to $BFFF to sectors 1 to 64. That is assuming you have a standard 8k cart.

A 16k cart would be $9000 to $BFFF, if I remember. And some carts do bank switching, so, you'd have to engage the different banks

and dump those to sectors on a disk.

Here's the part I don't know how people do, get the data from the sectors to a file.

I have a utility called RW13.COM that will write sectors on a disk to a file on another disk.

Anyway, that's what you have to do. But I'm old timey so I don't know what other utility Atarimax or elsewhere may have.

After you get the file, it is just a dump of the ROM, if it isn't a banked cart. You have to write your own header to the ROM to make it into

a binary load file, which requires you to write the load address and INIT and RUN addresses to a header.

Or you could probably just use the raw ROM file in Altirra or A8winplus4.

There are lots of configurations of carts. eg. OSS 034m, OSS M091 for OSS banked roms. Most carts are simple 8K or 16K ROMs.

 

Oh, I"m thinking also of the old cart copy schemes, like 'The Impossible' and some others. They require hot inserts, and you have

to have a dummy cart to insert to use the dumps. I don't recommend cart copy schemes other than Omnimon.

 

OH, also. I see FULS has mentioned the APE product to copy carts (the Atarimax USB Cartridge Programmer.) That may be

a lot easier way to dump carts.

Edited by russg
Link to comment
Share on other sites

Hi,

Mitch probably was referring to the "Maxflash USB Cartridge Programmer Kit"

http://www.atarimax.com/flashcart/documentation/

The Atarimax USB Cartridge Programmer main purpose is to program Maxflash Flash Cartridges, but will also dump your commercial carts as well.

This is a great product.

 

Edited by FULS
Link to comment
Share on other sites

Converting a file is not trivial. Especially if copy-protected. But if not protected, then as mentioned, the Atarimax Maxflash Studio software will allow you to put many executables into a form that can be flashed to cartridge or multi-cart format. If you truly want to create a romable file, then you need to study the Atari 800 technical notes. You must be fluent in assembler to have any chance for success.

Larry

Link to comment
Share on other sites

Way less trouble to just download it.

 

Only 8K ROMs will operate from the flash cart with guarantee the protection code won't make the machine crash.

The only reason to dump your own carts is if they're a proto or some other rare version that probably isn't available publicly.

Link to comment
Share on other sites

Russ - Bug/65 allows one to read raw sector data from D1: only into a desired address memory range and then write out that same memory range as a standard file. That's how I did it. Then of course the file needs a bit of tweaking with a disk editor to get one that loads where it's supposed to and INITs and RUNs correctly as well. Usually those two particular file headers are done at the end of a file so I guess we call it a Tailer instead of a header? Have never seen a good tutorial on file manipulation with a disk editor for this and other effects possible, I learned by the seat of my pants with many hard landings.

 

For carts that allow DOS to boot, one can go to DOS and just do a K SAVE memory from A000 thru BFFF or 9000 thru BFFF and save it as a file, no magic needed except to strip the Atari file header to make it a genuine ROM file. But many carts do not allow DOS to boot in the first place. And that's where the Omnimon OS shines, it can be made to boot with the the cart in the slot and full control going to the Omnimon code.

Link to comment
Share on other sites

Converting a file from a dos .exe or boot file is not trivial. Especially if copy-protected. But if not protected, then as mentioned, the Atarimax Studio software will allow you to put many executables into a form that can be flashed to cartridge or multi-cart format. If you truly want to create a romable file, then you need to study the Atari 800 technical notes. You must be fluent in assembler to have any chance for success.

Larry

The original poster wanted to make ROM dumps of his carts, if I understand. The strictly ROM dumped ROM file can only be used in an emulator, which isn't going to be

bothered if the cart had write to RAM copy protection check. If he OP wants to make executables of his carts, that can be straightforward or can be very involved if, say, a banked cart.

To make the .EXE/.COM would have to defeat copy protection RAM write checks. Like Larry says, isn't trivial.

Link to comment
Share on other sites

Russ - Bug/65 allows one to read raw sector data from D1: only into a desired address memory range and then write out that same memory range as a standard file. That's how I did it. Then of course the file needs a bit of tweaking with a disk editor to get one that loads where it's supposed to and INITs and RUNs correctly as well. Usually those two particular file headers are done at the end of a file so I guess we call it a Tailer instead of a header? Have never seen a good tutorial on file manipulation with a disk editor for this and other effects possible, I learned by the seat of my pants with many hard landings.

 

For carts that allow DOS to boot, one can go to DOS and just do a K SAVE memory from A000 thru BFFF or 9000 thru BFFF and save it as a file, no magic needed except to strip the Atari file header to make it a genuine ROM file. But many carts do not allow DOS to boot in the first place. And that's where the Omnimon OS shines, it can be made to boot with the the cart in the slot and full control going to the Omnimon code.

Right, the INIT/RUN is a 'trailer' not a 'header'. Never heard of Bug/65. The OP wants to copy his own carts. Maybe if he just gets a ROM file that works in emulator would be what he wants.

If he wants to make his own .EXE/.COM/.OBJ files, he'd have to be a regular hex editor, disassembler, code hacker. It has already been done and no need to do them again.

Link to comment
Share on other sites

Thanks for all the info!

 

Yes, I mostly wanted to make ROM dumps of my carts, for use in either an emulator or an SIO2something utility like APE or AspeQt.

 

It would be a lot easier to download them from somewhere, but if I wanted to do easy things I wouldn't be retro computing. I was also very curious as to how such ROM dumps were made, and I like the idea of giving my 35 year old Star Raiders cart immortality by letting it transcend its physical form and become pure data.

  • Like 1
Link to comment
Share on other sites

I would be insterested in learning how to do this too. Just purley for the geek factor ;)

OK, I typed this in while thinking. Keep in mind, I always make mistakes.

 

 

OK, you've dumped your 8K Star Raiders cart to a ROM file.

It is 8192 bytes pure ROM file.

Now all you have to do to make a .EXE/.COM/.XEX is tell

the disk drive where to start and end loading the 8192 bytes

and then tell the computer where to init and run in the

last six bytes of the .exe.

For this you need the 280 page 'Technical Reference Notes'.

You look up the cart initialization steps.

It will tell you that the last six bytes of a cart tell

the RUN and INIT address. All such bytes are in low byte,

high byte order.

So you need a hex editor if you want to see the last six

bytes of your file. A PC DOS executable program like

Von Buerg's LISTR.COM will do this. But we're just using

the Atari. So then you can inspect your ROM file.

You can use Disk Wizard to look at the end of the file.

Or... you can do a little BASIC.

10 CLOSE #1:OPEN #1,4,0,"D:STRD.ROM"

20 FOR N=1 TO 8192-6

30 GET #1,X

40 NEXT N

50 FOR N=1 TO 6

60 GET #1,X

70 ? X;",";

80 NEXT N

90 CLOSE #1:REM Never leave a channel open

Now you see the last six bytes.

In practice the last two bytes almost always is the RUN address

even tho it is the INIT address. If you go to INIT something

that doesn't need INITing, then you can just RUN it.

The last two bytes are 74 and 161 ($4A and $A1).

So SR runs at $A14A.

(Oh yes, you gotta get a HEX calculator along with your Tech. Ref.)

Now you're ready to make your .exe file

You need the first six bytes to be LOAD START LO, L.S. HI,

LOAD END LO, LE. HI.

That would be start at $A000 and end at $BFFF.

so you write the header.

10 CLOSE #1:OPEN #1,8,0,"D:MYSR.EXE"

11 REM YOU GOTTA WRITE YOUR .EXE AND READ YOUR .ROM

12 CLOSE #2:OPEN #2,4,0,"D:MYSR.ROM"

14 PUT #1,255:PUT #1,255:REM ALWAYS START W $FF,$FF

20 PUT #1,0:PUT #1,160:PUT #1,255:PUT #1,191

30 REM NOW YOU HAVE THE LOAD START AND END

40 REM NOW PUT THE CODE IN

50 FOR N=1 TO 8192:GET #2,X:PUT #1,X:NEXT N

60 REM NOW DO THE LAST 6 BYTES

70 REM YOU GOTTA HAVE 'MAPPING THE ATARI', IT HAS RUN ADR AT $2E0, $2E1

80 REM WHEN THE DRIVE LOADS THE $2E0,$2E1, IT KNOWS TO RUN AT THE ADR LO, HI IN $2E0,$2E1

90 PUT #1,224:PUT #1,2:PUT #1,74:PUT #1,225:PUT #1,2:PUT #1,161

100 CLOSE #1:CLOSE #2:REM YOU'RE DONE.

 

All 8K carts start at $A000 and end at $BFFF

Edited by russg
Link to comment
Share on other sites

I would be insterested in learning how to do this too. Just purley for the geek factor ;)

(I told I made errors)

it should be:

90 PUT #1,224:PUT #1,2:PUT #1,225:PUT #1,2:PUT #1,74:PUT #1,161

You tell lo, hi where and then lo hi run address.

I tried it with my PACMAN cart. It doesn't work. I think that is because PACMAN has a real INIT and RUN instead

of just a RUN like STAR RAIDERS.

Also note that I'm assuming there is no copy protection scheme going on. For that, you'd have to use

a disassembler and find the protection scheme, a bit harder to do.

Link to comment
Share on other sites

(I told I made errors)

it should be:

90 PUT #1,224:PUT #1,2:PUT #1,225:PUT #1,2:PUT #1,74:PUT #1,161

You tell lo, hi where and then lo hi run address.

I tried it with my PACMAN cart. It doesn't work. I think that is because PACMAN has a real INIT and RUN instead

of just a RUN like STAR RAIDERS.

Also note that I'm assuming there is no copy protection scheme going on. For that, you'd have to use

a disassembler and find the protection scheme, a bit harder to do.

My PACMAN ROM dump works in Altirra. My .EXE doesn't work. PACMAN has an opening INIT and maybe some copy protection.

I still think the Star Raiders .EXE will work, it has no INIT. maybe.

Your Omnimon dump of SR should work in Altirra.

Those last six bytes of the ROM dump are:

BFFA-B RUN address

BFFC - a zero always

BFFD an option byte see Tech Ref. a 4 means INIT and then RUN

BFFE-BFFF the INIT address (can be RUN from if no INIT is needed)

Edited by russg
Link to comment
Share on other sites

Are you asking how to dump a cart? I would guess that the easy way is to intercept the S4/S5 lines that select the cart ROM. This will make the system think that there is a cart installed but it has no INIT or RUN address. It will be effectively ignored. Plug in the cart, disable S4/S5, boot up into DOS, enable S4/S5, and SAVE $A000-$BFFF (or $8000-$BFFF if 16K). The resulting file will have a six byte header appended to it.

 

Should work.

 

Bob

Link to comment
Share on other sites

Are you asking how to dump a cart? I would guess that the easy way is to intercept the S4/S5 lines that select the cart ROM. This will make the system think that there is a cart installed but it has no INIT or RUN address. It will be effectively ignored. Plug in the cart, disable S4/S5, boot up into DOS, enable S4/S5, and SAVE $A000-$BFFF (or $8000-$BFFF if 16K). The resulting file will have a six byte header appended to it.

 

Should work.

 

Bob

A hardware solution. S4 & S5 pins 1 and 12 of the cart slot. How you intercept/enable/disable the S4/S5 lines?

Link to comment
Share on other sites

A hardware solution. S4 & S5 pins 1 and 12 of the cart slot. How you intercept/enable/disable the S4/S5 lines?

I believe Dropcheck's Super MMU Adapter would simplify this, there is a header block which allows rerouting the S4/S5/RD4/RD5 signals if desired. There's not much information about this feature except for the link to Cart Dump Schematics.

Link to comment
Share on other sites

Guys, especially Russ G, thank you, you have answered a problem I had when a friend and I wrote a multiboot style menu loader back in the day, it was lovely with the EA loading sprites and all sorts on the screen font and sprite wise but we had one problem, we didn't know that the load and init was at the END of the file for roms, they were the only items we had issues with and we never solved it..

 

Until today...

 

If my old mate Steve Harley is reading this, look Steve, its there :)

 

I don't know what Steve did with his Atari gear, would have been great to go back and fix that issue now but I think its now all lost but finally to get an answer..Great..

Edited by Mclaneinc
Link to comment
Share on other sites

In the day I made this cart extender with switches on the select lines so you wouldn't have to hot-insert a cart. You would have to leave the cart door open, though, and jam something into the door interlock switch, like Keith Emerson's knife.

post-18605-0-05104200-1405771653_thumb.jpgpost-18605-0-31583400-1405771971_thumb.jpg

I wrote a ROM dump utility and a cart image disk boot loader. For protected carts, I designed and built this RAM write-protect circuit.

post-18605-0-89782700-1405771676_thumb.jpgpost-18605-0-48189800-1405771691_thumb.jpg

If you're interested, I can search for the dump and boot software and post it.

 

  • Like 2
Link to comment
Share on other sites

You could use the BasicENable line into the MMU as a switch. This would need a new MMU but would not require any soldering or such. (if your MMU was socketed)

 

Or, you could open the circuit from MMU 12 and 19 with a 1.8K resistor to +5v on CART pins 1 and 12.

 

The new MMU is pretty simple - I'll try one and let you know.

 

Bob

 

 

 

A hardware solution. S4 & S5 pins 1 and 12 of the cart slot. How you intercept/enable/disable the S4/S5 lines?

Link to comment
Share on other sites

To follow up on the disk editor approach where I cut my teeth on, I would start with a formatted disk with nothing else on it and do a K Save from DOS from A000 to A060 first (16K - 8000 to 8060). This will result in a one sector file at sector 4 (DOS 2.0 type), we use that to gather the first six bytes of the cart data proper and transplant them into the next file saved. The second file saved is from A006 thru BFFF (16K - 8006 thru BFFF), the starting sector of which will be at sector 5. Then using the disk editor, replace the standard Atari file headers bytes on the 2nd file at sector 5, offset 0 ( FF, FF, 06, A0, FF, BF) with the first six bytes of the cart data gleaned from the first file and those bytes would start at byte offset of 06 in the first file. You now have a ROM file in the second file and no other processing is required except to move it to a PC where you can actually use it. On the Atari it is treated as a text file or raw data file with no loading addresses included, once the original double FF is overwritten. On the disk, it still contains next sector links etc., so we can't just read consecutive sectors out and call it a ROM file if we had that capability in the first place (ie., Bug/65 or very talented disk editor), but DOS will automagically strip those when the file is moved.

 

Liking the Keith Emerson touch too.

Link to comment
Share on other sites

A hardware solution. S4 & S5 pins 1 and 12 of the cart slot. How you intercept/enable/disable the S4/S5 lines?

Replacement firmware for the SpartaDOS X cartridge is available for use with cartridge dumping, these cartridges already have control of the S4/S5 signals on the passthru port. This firmware is available at the bottom of the following page:

https://sites.google.com/site/ataripal/cartdump

  • Like 2
Link to comment
Share on other sites

There's a couple of inordinately simple ways of doing it if you get lucky. Easiest IMHO is just get OMNIMON OS in some flavor. With the cartridge inserted you just press reset while holding down the OPTION + SELECT keys and that gets you to the monitor. From the monitor, just type B with a DOS disk in your drive and you will be at the DOS menu. A simple binary save of the cartridge address will save the image with the aforementioned 6 header bytes. Kind of neat to have a game cart inserted with the DOS menu staring at you.

 

There's some odd stuff Atari did to save a buck. Lots of their 8k carts took up the full 16k but only had one ROM inserted. All you do to copy the binary is pull the existing EPROM<or ROM>, move it to the other socket, and insert a BASIC EPROM<or ROM, whichever the case may be> into the original occupied socket and boot the cart. It will come up 8k short of free RAM for BASIC *BUT* the 8k address space will be the original cart ROM.

 

There's some variation on the second method. If you modify the cart lines, you can actually have a cart that only goes from $8000-$9FFF. You can boot to built in BASIC on an XL this way and still have the ROM of interest in the memory map.

Link to comment
Share on other sites

I modified the 800XL MMU so that the internal BASIC is replaced by the cartridge you have plugged into the system. If you boot normally with no cartridge or boot with OPTION pressed, the cart is disabled. In the first case, you have 40K of memory (boot with no cart and press OPTION for 48K). In the second case, the cart is disabled but it still 'locks out' either 8K or 16K, depending on the size of the cart. You want to do this so that the OS does not put your screen in the cartridge space.

 

If you plug in a cart and power on without pressing OPTION, the system comes up normally with the cart functional.

 

So, the procedure is: plug in a cart: power on with OPTION pressed: load your dump code: clear bit 1 in $D301 with your dump code (this enables the cart): dump 8K or 16K.

 

As with anything 'different', some programs are bound to want to help and disable BASIC for you, which disables the cart, instead. You can still dump the cart OK, but you can't run it.

 

Here are two files, the CUPL code and the JEDEC output. I used an ATMEL ATF16V8B chip so the JEDEC file is only good for that. You may need to change the Target chip and re-compile if you are using another device.

 

All I did in the code is disable the BASIC output and add !BE to S4 and S5.

 

Try it!

 

Bob

 

 

800XLCOPY.zip

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