sage

Just to update this information. I compiled it with mono under Ubuntu 11.10 and (after a few minor fixes) it worked. There are still some flaws, but basically it works.

Well, you will never get the timing right. But anyway. There is actually really a loader cartrigde, which is eh quiet useless, as the loader is embedded in several games. Alpine Games, Champ Rally, , Simis, Lynx Reloaded and maybe some of the newer homebrews.

yes ->PM

And finally, I found out why it did not work in handy, while it worked fine in mednafen. for some reason handybug throws three bombs if it used. lynxtest.bin

Duranik website? Oh oh, them redesigned it, have a new game in the pipeline... but still der email adress is there.

Now cc65 created images boot fine (Karris "micro" loader). lynxtest.bin (updated) Edit: 512kb BLL titles now also working

original games work fine, but the troyan horses might make problems, at least one of the roms is done with an old lynxer version, most like on the ST, which differs from the one I (and most others) were using. What will not be working is the "variety of boot schemes" ThomH wants to use, while Dave's micro loader will work in the next version (I just have to change a few lines). My goal is not to have a rom which is a complete and identical replacement, but one which loads the commerical ones fine (therefvore can be shipped with the emulator) and can be used by _myself_ for developing.

its know that there are differences in the emulation of the mult/div compared to real hardware. But if you do mult/div as you should do it, the behaviour is o.k. PS: for this simple test a serial cable is more useful...

I know alreday two ROMs which do not work, one I know why, for the other not. Would be nice if some ppl can test and tell me if there are more. Ah yes, the title picture is skipped on purpose. The file has to be renamed and copied to the directory the emulator looks for it. For mednafen its $HOME/.mednafen/lynxboot.img lynxtest.bin

I still dont understand neither your remark nor .. what you want to tell me with this sentence. I have no idea what your variety of "boot schemes" might be.

Fantastic work! So it's a new drop-in ROM replacement for any old emulator, that I could in theory use on original hardware? if you replace your main cpu, yes. As you have actually no idea what and how I do it, I do not see how you can come to that conclusion. I'm on-and-off working on a new development environment, in which you write whatever code you want for the encrypted bootstrap. If you wanted to go with the serial media metaphor then that'd be your own business, as I certainly won't be going to any effort to support it. I'm probably still a few weeks away from having any working ROMs but would it be helpful to send some over with a variety of boot schemes when the moment comes? I do not understand your argument.

for A and B, just clean the contacts below the buttons. they use graphite for getting the contact, and somtimes there is a little graphite dust under the button. is this is not working yet, it might be that the rubber is a bit old. what you can do then, is to add a small additional spacer, like a piece of paper or tape with a hole wher the contact has to be.

Just to let you know. I successfully did a lynxboot.img replacement based only on "free" sources, without reverse engenieering the original ROM (which is the major point to get it "free"). It might not work for all future ROMs but for what I tried until now it is working (used in mednafen). There are still two issues which I would like to solve before publishing esp I need to test more ROMs.

>Has anybody got Mednafen to run Lynx stuff in 64-bit mode? I can get it to work in 32-bit mode but 64-bit just gives me a black Lynx screen. The mednafen help and other stuff show up as they should so I assume that the Lynx emulation is not 64-bit safe. Did you run the 32 bit verseion on a 64 bit system or a native 64 bit version? For the later it may very well be that varaibles (pointers) chnaged size and as stuff is partly quiet lowlevel...

make a md5sum for each rom and depending on that read the dir at 410, 512 or 896. yes, no problem.

you misunderstood the question. he asks for a lynxboot.img replacement.

Which disassbler do you use?

have you seen my post about the loader/header types? What do oyu thing the script is doing? Nobody talks about the BLL gautlet loader here. This is the loader which lynxdir uses. Its an epyx loader where the checksumming is disabled and where the adress for the binary and title picture are read from the directory and NOT stored in the encryoted part. Just a few lines of fixes...

Let me just point out, that actually the only use for teh encrypted header is, that it contains a checksum for the whole ROM. If you dont want the checksum, you can simple use the hacked loader, which can just be copied in front of the ROM.

looks so

1) BLL is not needed, just one assembler for the 6502 code, lyxass ist just what i am used to ... well eh and a dissassmbler to get the code of a module 2) yes 3) https://bitbucket.or...rc/58e88930582a 4) no idea where the source came from, it just popped up somewhere (how about google for buildchk epyx)?

yes and no, if you do a FULL reset, the baudrate will be switched back to 9600, but if you only press it short, the baudrate stays and only the menu is shown again.

If I look at the timestamps on my harddisk, yes, its a bit late :-)

And as its Xmas, I updated the lynxdir ROM (directory) builder. Features: 128, 256, 512kb ROM size support uses BLL or EPXY style directories, even in same module BLL compatible headers possible, even with EPYX header Troyan entry (for compatibility reason) possible detects and marks packet files stripping unnecessary headers block aligning Checksumming in loader is disabled, thus no encryption is needed steering by script file for complex projects steering by command line for simple mode (just one .o file for quick tests) support for small internal logo if none is given in script

As this is useless for most people, I decided to release it as kind of a X-mas decoration. Useless, but nice to look at. This script creates a new encoded header including checksumming for a 256kb ROM. Thus automating the process of encoding which is described elsewhere. As are the sourcecodes for the programs. The encodes stage 2 you can just copy of any of the newer commerical ROMs. The stage 1 source you would have to decode and reassemble from any of the newer commerical ROMs. #!/bin/bash echo "Add a loader to a 256kb ROM (well 1024bytes/block)" echo "Process $1, get dir entries" buildchk $1 256 echo "now romdir.i and checkstring.src have been created" echo "next assmble new stage1 using loader_stage1.asm" lyxass -d -o "$1.stage1_plain" loader_stage1.asm lynxenc "$1.stage1_plain" "$1.stage1_enc" OUT="$1_mod.lyx" echo "Copy Image file to new name... $OUT" cp "$1" $OUT ## Now write the stage 1 part (which depend on file dir) SIZE1=154 dd if="$1.stage1_enc" of="$OUT" bs=1 count=$SIZE1 conv=notrunc ## Now write the stage 2 part SIZE2=256 dd if="loader.stage2_256k_enc" of="$OUT" bs=1 count=$SIZE2 conv=notrunc seek=$SIZE1 OUT2="_$(basename "$OUT")" echo "Now make a lnx... $OUT" mv $OUT "$OUT2" make_lnx "$OUT2" -b0 256k echo "Finished"