sage

I have some more wishes for a future version Call Pattern/Return would be one of them

-> PM

Thanks for the information. Seems I have understood most of it -> see PM If I look in your code, you reset the Timer every tick, even so the replay freq has not changed, which disturbes the freq a bit.

Yes, exactly. So crazy things can be done with that if needed. Ah, and will an "embedded" delay of 0 wait for 0 or 256 ticks?

Yes, exactly. So crazy things can be done with that if needed. Good. Now I need to change the replay frequency. Are there any traps or is it enought to move the player to another timer? Next: I need more space for the music, can I (in your example programm) just change the adresses or will that have some side effects?

The first command in an instrument script is processed one frame after the music script's note on. But the channel in hardware is not turned on until this time as well, so there is no distortion from setting things the previous frame. O.k. thus setting the volume in the header has no effect if the first command is a change volume command, right?

Yes it did. Other thing: In an instrument script, is the first command in the script parsed at time zero or one after note on?

I tried to play a bit with your engine, but I have a problem converting actual notes to the values which your driver accepps. at least it seems what it plays is not want I wanted it too. Maybe you can help by providing the function which you used to convert a note (=frequency) into your 16.8 format

The bit which is set, if a sprite is off-screen (EVERON). i think collision detection must be switched on for that, but i am too lazy to read the doc now. Keith tried to fix that in the lastest release, but i think the bug is still in. Bastians demo is in the BLL kit as asm source code. either demo006.asm or drawtest.asm, both have the same problem. Add: The problem comes from the file fpolygon.inc which is drawing the actual filles polygons. Add: I tried to attach the sourcecode, but looks like this is not allowed.

The sound works better in mednafen, but as its using the same engine, its really a sound buffer problem.

From my memory... Sprite drawing: Real hardware is accepting "wrong" spritedata, emulation only the one specified in docs. (Bastian's Cube demo) Out of Screen/End of Life Bit is not correctly set (sometimes). (have to look for my example code...) Scaled sprites are sometimes off by one pixel (guess: rounding? wrong fractions?) Multiply/Divide behaves differently, I think esp if signed math is used. (have to look for my example code...)

well it prevents the cartridge from vanishing if you show this around

Well thats good that there are now several music tools for usage available. Bad only nobody wants to use them :-b Hear some test here: http://lynx.syntaxparty.org/tests/ Or if you have a flashcart: lynxdev.atari.org/flashcart_slideshow.lnx

As the game contains a checksum, it can not be dirty contacts. For the PSU there is no big problem, you can use nearly any Voltage between 9-12V.

you dont have to care about speed if you anyway send the packets by "software" lets say udp.

I like the idea that someone takes over the handy development and fixes the bugs, crappy sound etc which are still in. Even in the nevest version there was a bug in collision of scaled sprites and the out of screen bits. And, a improved debugging version would be very welcome. But... I think it would be much much better to continue work on the sdl port, as this is the one which is used on all other emulators (mednafen), machines and handhelds. Actually, with handhelds it really makes sence to improve the comlynx over udp of handy. Anyway, as long as the development will be only for one or two systems, I will not invest my time, sorry. I will put together a list of suggestions.

For a second I thought its a "he" editon, but oviously, it looks just like a painted one.

Karris reworked version, yes. BLL version, no, there you needed lynxer. BLL lyxass assembler, same here.

Found the windows executeable, but it migh need some dlls. Remember its a command line utility and you have to modify one of the config files.

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. 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: assemble/compile your binary For BLL development software: use lynxer to create the rom image (onyl 1025 bytes/block with a cracked version of the encryped loader called "troyan horse" 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.

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

Go one step back and read erics msgs. He says it was a ROM without a loader code, where .... ehm .... somebody .... added the loader code

Actually, as teh command are the same for 56 and 66 and 76 and 86 you should also be able to access these. 93c46 - a 128 byte eeprom 93c66 - a 512 byte eeprom (and 93c56 - a 256 byte eeprom) 93c86 - a 2048 byte eeprom (and 93c76 - a 1024 byte eeprom)

As much as I appreciate the effort put into the program, I have to admit that I have never seen anything more complicated. Except women. I agree...

Would be nice.