Jump to content
IGNORED

Booting from ROM (.LNX)


mic_

Recommended Posts

I've been looking at various sources, and from my understanding the whole 64kB physical memory space is seen as RAM, except for the top 1kB which by default contains the system ROM, MMIO, etc. So to make use of the code/data on your cart I guess you'll first have to load it into RAM through the RCART registers(?).

 

That's fine I suppose, but I don't see how my code in an .LNX files actually starts running at boot. When I look at a disassembled system ROM (lynxboot.img) I only see it loading 50 bytes from the cart to $AA-$DB, and when I take a look at what those 50 bytes actually are in e.g. Lynxopoly they don't seem to contain anything meaningful (unless the data is encrypted).

 

Is there any info available on this subject? I.e. what part of an .LNX file is first executed, from what address is it executed, and how has the hardware been set up at that point?

Link to comment
Share on other sites

I've been looking at various sources, and from my understanding the whole 64kB physical memory space is seen as RAM, except for the top 1kB which by default contains the system ROM, MMIO, etc. So to make use of the code/data on your cart I guess you'll first have to load it into RAM through the RCART registers(?).

 

That's fine I suppose, but I don't see how my code in an .LNX files actually starts running at boot. When I look at a disassembled system ROM (lynxboot.img) I only see it loading 50 bytes from the cart to $AA-$DB, and when I take a look at what those 50 bytes actually are in e.g. Lynxopoly they don't seem to contain anything meaningful (unless the data is encrypted).

 

Well, as you guessed, its encrypted.

the lynx ROM diencrypts that part which then load teh cartridge, actually, its not 50 bytes but more like or

154 or 256, depending on teh loader type.

 

Is there any info available on this subject? I.e. what part of an .LNX file is first executed, from what address is it executed, and how has the hardware been set up at that point?

 

yes, quiet a lot. but its too complicated to be put in a few sentences.

the decrypted loader code (supplied by epxy) loads the first two files of the directory, the first is diplayed as title picture, the second executed.

Thats the reason you need a directory builder to craete a ROM image (lynxer for BLL kit, or similar thing for EPYX tools).

Everything from this directory on is not encrypted ... at least if the game programmes didnt do by themself... lynxopoly is party packed... well not encrypted :)

Link to comment
Share on other sites

Ok. So is the encrypted loader standard? I.e. could I just take the first 256 bytes after the LNX header from whatever game and put it in my own ROM? And is there a disassembly of a decrypted loader somewhere that I could look at?

 

What I need to know is mainly how much of my own code that will be "automatically" loaded from the cart to RAM, from where, and to where (i.e. what ORG should it have?).

Link to comment
Share on other sites

I.e. could I just take the first 256 bytes after the LNX header from whatever game and put it in my own ROM?

 

no cause you dont know the directory system, startbyte of the directory, alignments etc. its different from game to game and romtype to romtype (128K,256K,512K)

Link to comment
Share on other sites

Ok. So is the encrypted loader standard? I.e. could I just take the first 256 bytes after the LNX header from whatever game and put it in my own ROM? And is there a disassembly of a decrypted loader somewhere that I could look at?

 

No. because the encrpyted loader contains a checksum and use and encrypted copy of two first entries of directory.

 

Yes, if you use a "cracked" version of the encrypted loader where these features have been removed.

(see below)

 

nevertheless, you need to create the directory.

 

What I need to know is mainly how much of my own code that will be "automatically" loaded from the cart to RAM, from where, and to where (i.e. what ORG should it have?).

 

Thats up to you. You assembler/compiler sould have this information in the binary and during cart/directory building this information is stripped and written to the directory.

 

So normally what you do is the following:

 

  1. assemble/compile your binary
     
  2. For BLL development software:

    1. use lynxer to create the rom image (onyl 1025 bytes/block with a cracked version of the encryped loader called "troyan horse"
    2. different version of lynxer are floating around in the net, even with source code... for linux, windows, atari st...

[*]For others:

  • use a chain of scripts/programs (epxy amiga source ported to linux) to create the ROM, read directory, use it to assemble the loader, encrypt the loader, write to ROM image, support for 512, 1024 and 2048 bytes/sector
  • if have a script which is doing that ony my linux dev system automatically

[*]For all:

  • use a lynxdir which has teh option to put a cracked loader for any type of ROM image, EPXY and BLL style images supported as well as for 512, 1024 and 2048 bytes/sector.
  • runs on linux and windows, send me email and I mail it to you

[*]use make_lnx (from handy) to add the header needed for the emulator.

Link to comment
Share on other sites

Cool, thanks.

I noticed that cc65 has support for outputting straight to .LNX, so I'll probably try that out first. And if I'm unhappy with cc65 I'll take a look at all those other tools.

 

Karris reworked version, yes.

BLL version, no, there you needed lynxer.

BLL lyxass assembler, same here.

Link to comment
Share on other sites

  • 2 weeks later...

Here's the article I wrote after I cracked the private key needed for encrypting lynx ROMs: http://www.classicgamedev.com/Blog:Hacking_Classics/Lynx_Encryption

 

Then after fully understanding how the boot process worked, I designed a new "micro loader" to replace the old boot system: http://www.classicgamedev.com/Blog:Hacking_Classics/Micro_Loader

 

It is a bare minimum boot loader that doesn't use a complicated file system or anything. It just sets a few registers and then loads a secondary loader that is more complex. The micro loader just gets you past the decryption step with minimal work.

 

The micro loader and encryption code has now been incorporated into the cc65 toolchain so that you can create a complete .lnx rom ready for use on real hardware.

 

I am also encorporating it into my HLAKit compiler: https://bitbucket.org/wookie/hlakit/overview and docs: http://hlakit.classicgamedev.com/Home

 

HLAKit is still a work in progress and not usable but I link to it here because the full source code for my latest micro loader and secondary loader can be found in the examples/6502/lynx directory in the source repo. The source files contain verbose comments that explain everything that the code does and how the boot process works.

 

--wookie

Link to comment
Share on other sites

  • 6 months later...

Wookie (or perhaps Karri, sage, etc.)

Is this loader above available for use?

 

For instance if someone wants to load the front part to a headerless rom... where can we get the files and is it available.

I'm currently consolidating all of my old Lynx files onto one computer (right now it is spread to 4 different computers) and I'd like to get everything all together and write myself a 'how-to guide' so I can quit forgetting how I did this stuff in the past.

Link to comment
Share on other sites

Eric, depending to which of our answeres you are referring, the answere is yes.

 

>>For instance if someone wants to load the front part to a headerless rom... where can we get the files and is it available.

 

this is something different and has nothing to do with the topic discussed here.

 

What you most likely want to do is using a hacked loader and put it in fron of your ROM image _or_ just reencrypt the ROM (which also creates a loader an the fly).

this works only for roms where the directory starts after 410. this might not be the case for all roms, esp if you have protos, as epyx changed the position of the directory from 512 to 410 at some point.

 

The first thing you can do with

dd if=hackedloader of=yourimage bs=1 count=410 conv=notrunc

the hacked loader are embedded in lynxdir, you just can get them from it by creating a cartridge and reading the first 410 bytes.

 

for the second solution you would need to call a few programs after each other. i have script for that, but i do not want to put this to public as it depends on a few things where the licence is not clear.

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